在我的 iOS 应用程序中，我想缓存从不同目的地请求的图像。对于下载图像，我使用 URLSessionDataTasks 和 URLSession.shared 提供的默认缓存机制，它利用了 NSURLRequestUseProtocolCachePolicy。
缓存工作基本正常。正在缓存响应，并且正在正确处理诸如 etag 和缓存控制“max-age”之类的缓存标头。但是，如果服务器响应缓存控制标头设置为“no-cache”，则 URLSession 的 URLCache 仍在缓存图像。我可以通过 URLCache.shared.cachedResponse(for: request) 访问缓存的响应，并且具有相同请求的新数据任务将从缓存中返回时间图像（我使用 Charles 代理进行了验证，但我没有看到请求我正在等待）。
为什么它不能正确处理响应的缓存头？是否需要手动检查响应的缓存标头？
【问题讨论】：
标签： ios caching nsurlsession no-cache
no-cache 指令并不意味着“不要将其存储在缓存中”。相反，它指示缓存在没有先与服务器验证的情况下不提供缓存的响应。 [RFC7234][1] 规范对no-cache 指令进行了以下说明。
“no-cache”响应指令表明响应不能 用于在未成功验证的情况下满足后续请求 在源服务器上。这允许源服务器阻止缓存 从使用它来满足请求而不联系它，甚至通过 已配置为发送陈旧响应的缓存。
如果 no-cache 响应指令指定一个或多个字段名称， 然后缓存可以使用响应来满足后续请求， 受到任何其他缓存限制。但是，任何标题 响应中列出的字段名称的字段不得为 在对后续请求的响应中发送但未成功 与原始服务器重新验证。这允许源服务器 防止在响应中重复使用某些标头字段，同时仍然 允许缓存响应的其余部分。
因此，对于带有no-cache 指令的“新鲜”响应，将发送一个条件请求来验证是否可以使用存储的响应。如果响应仍然有效，服务器将发送304 - Not Modified 响应。收到304 响应后，缓存将使用no-cache 指令提供存储的响应。如果存储的响应不再有效，服务器将发送一个新的响应。
[1]：https://www.rfc-editor.org/rfc/rfc7234#section-5.2.2
【讨论】：