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指令為存儲的響應提供服務。 如果存儲的響應不再有效，則服務器將發送新的響應。