在我的iOS应用中，我希望缓存来自不同目的地的图像。为了下载图像，我使用URLSessionDataTasks和URLSession.shared提供的默认缓存机制，该机制使用NSURLRequestUseProtocolCachePolicy。
缓存工作基本上没问题。正在缓存响应，正确处理etag和缓存控制“max-age”等缓存标头。但是如果服务器响应缓存控制头设置为“no-cache”，则URLSession的URLCache仍然缓存图像。我可以通过URLCache.shared.cachedResponse（for：request）访问缓存的响应，并且具有相同请求的新数据任务将从缓存返回时间图像（我通过使用Charles代理验证，我没有看到请求我在等待。）
为什么不能正确处理响应的缓存头？我是否需要手动检查响应的缓存标头？
答案 0 :(得分：0)
no-cache指令并不意味着“不将其存储在缓存中”。相反，它指示缓存不提供缓存的响应，而不首先使用服务器进行验证。 RFC7234规范说明了no-cache指令的以下内容。
“no-cache”响应指令表明响应必须不是 用于满足后续请求而无需成功验证 在原始服务器上。这允许源服务器阻止缓存 使用它来满足请求而不联系它，即使是 已配置为发送过时响应的缓存。
如果no-cache response指令指定了一个或多个字段名， 然后缓存可以使用响应来满足后续请求， 受缓存的任何其他限制。但是，任何标题 响应中具有列出的字段名称的字段绝不可以 在没有成功的情况下发送了对后续请求的响应 使用原始服务器重新验证。这允许源服务器 防止在响应中重复使用某些标头字段 允许缓存其余的响应。
因此，对于使用no-cache指令的“新鲜”响应，将发送条件请求以验证是否可以使用存储的响应。如果响应仍然有效，服务器将发送304 - Not Modified响应。收到304响应后，缓存将使用no-cache指令提供存储的响应。如果存储的响应不再有效，服务器将发送新响应。