URLResponse已缓存，尽管响应的缓存控制标头设置为no-cache

Question

在我的iOS应用中，我想缓存从不同目的地请求的图像。 为了下载图像，我使用URLSessionDataTasks和URLSession.shared提供的默认缓存机制，该机制利用了NSURLRequestUseProtocolCachePolicy。

缓存工作正常。 正在缓存响应，并且已正确处理了etag和缓存控件“ max-age”之类的缓存头。 但是，如果服务器在将缓存控制标头设置为“ no-cache”的情况下进行响应，则URLSession的URLCache仍将缓存图像。 我可以通过URLCache.shared.cachedResponse（for：request）访问缓存的响应，并且具有相同请求的新数据任务也会从缓存中返回时间图像（我通过使用Charles代理进行了验证，但没有看到请求）我正在等待）。

为什么它不能正确处理响应的缓存头？ 我需要手动检查响应的缓存头吗？

Answer 1

no-cache指令并不意味着“不要将其存储在缓存中”。 相反，它指示缓存在不先与服务器验证的情况下不提供缓存的响应。 RFC7234规范对no-cache指令进行了以下说明。

“ no-cache”响应指令指示在未经原始服务器成功验证的情况下，不得将响应用于满足后续请求。 这样，即使已配置为发送过期响应的缓存，原始服务器也可以防止缓存使用它来满足请求而无需联系它。

如果no-cache response指令指定了一个或多个字段名，则缓存可以使用该响应来满足后续请求，但要遵守其他对缓存的限制。 但是，如果没有使用原始服务器成功进行重新验证，则响应中具有列出的字段名称的任何头字段都不得在对后续请求的响应中发送。 这使源服务器可以防止在响应中重复使用某些标头字段，同时仍允许缓存其余响应。

因此，对于带有no-cache指令的“新”响应，将发生条件请求，以验证是否可以使用存储的响应。 如果响应仍然有效，则服务器将发送304 - Not Modified响应。 收到304响应后，缓存将使用no-cache指令为存储的响应提供服务。 如果存储的响应不再有效，则服务器将发送新的响应。