Cache-Control: max-age=0 和 no-cache 有什么區別？

Question

標頭Cache-Control: max-age=0暗示內容立即被認為是陳舊的（並且必須重新獲取），這實際上與Cache-Control: no-cache 。

Answer 1

我有同樣的問題，並在我的搜索中找到了一些信息（您的問題是結果之一）。 這是我確定的...

Cache-Control標頭有兩個方面。 一側是它可以由網絡服務器（又名“源服務器”）發送的地方。 另一端是瀏覽器可以發送的地方（又名“用戶代理”）。

---

由源服務器發送時

我相信max-age=0只是告訴緩存（和用戶代理）響應從一開始就已經過時，因此他們應該在使用緩存副本之前重新驗證響應（例如，使用If-Not-Modified標頭），而, no-cache告訴他們在使用緩存副本之前必須重新驗證。 從14.9.1 什么是可緩存的：

無緩存

...緩存不得使用響應來滿足后續請求，而無需與源服務器成功重新驗證。 這允許源服務器阻止緩存，即使緩存已配置為向客戶端請求返回陳舊的響應。

換句話說，緩存有時可能會選擇使用陳舊的響應（盡管我相信他們必須添加一個Warning標頭），但no-cache表示no-cache都不允許他們使用陳舊的響應。 也許您希望在頁面中生成棒球統計數據時使用SHOULD -revalidate 行為，但是當您生成對電子商務購買的響應時，您希望使用MUST -revalidate 行為。

盡管當您說no-cache不應阻止存儲時，您的評論是正確的，但實際上可能是使用no-cache時的另一個區別。 我遇到了一個頁面， Cache Control Directives Demystified ，上面寫着（我不能保證它的正確性）：

在實踐中，IE 和 Firefox 已經開始處理 no-cache 指令，就好像它指示瀏覽器甚至不要緩存頁面一樣。 大約一年前，我們開始觀察這種行為。 我們懷疑此更改是由該指令的廣泛（且不正確）使用以防止緩存引起的。

...

請注意，最近，“cache-control: no-cache”也開始表現得像“no-store”指令。

順便說一句，在我看來， Cache-Control: max-age=0, must-revalidate應該基本上與Cache-Control: no-cache意思相同。 所以，也許這是一種方式來獲得的MUST -revalidate行為no-cache ，同時避免了明顯的遷移no-cache在做同樣的事情， no-store （即沒有任何緩存）？

---

由用戶代理發送時

我相信shahkalpesh 的回答適用於用戶代理方面。 您還可以查看13.2.6 消除多重響應的歧義。

如果用戶代理使用Cache-Control: max-age=0 （又名“端到端重新驗證”）發送請求，那么沿途的每個緩存都將重新驗證其緩存條目（例如，使用If-Not-Modified頭）一直到源服務器。 如果回復是 304（未修改），則可以使用緩存的實體。

在另一方面，與發送請求Cache-Control: no-cache （又名“終端到終端重裝”）不重新確認和回應當服務器不能使用的緩存副本。

Answer 2

最大年齡=0

這相當於單擊Refresh ，這意味着，除非我已經擁有最新副本，否則給我最新副本。

無緩存

這是在單擊刷新的同時按住Shift ，這意味着，無論如何都要重做一切。

Answer 3

現在是老問題，但如果其他人像我一樣通過搜索遇到這個問題，IE9 似乎將利用它來配置使用后退和前進按鈕時的資源行為。 當使用max-age=0 時，瀏覽器將在后退/前進按壓上查看資源時使用最新版本。 如果使用no-cache ，資源將被重新獲取。

有關 IE9 緩存的更多詳細信息，請參閱此msdn 緩存博客文章。

Answer 4

在我最近對 ​​IE8 和 Firefox 3.5 的測試中，似乎兩者都符合 RFC。 但是，它們對原始服務器的“友好度”有所不同。 IE8 使用與max-age=0,must-revalidate相同的語義處理no-cache響應。 然而，Firefox 3.5 似乎將no-cache視為等同於no-store ，這在性能和帶寬使用方面都很糟糕。

默認情況下，Squid Cache 似乎從不存儲任何帶有no-cache標頭的內容，就像 Firefox 一樣。

我的建議是為非敏感資源設置public,max-age=0 ，您希望在每個請求上檢查新鮮度，但仍然允許緩存的性能和帶寬優勢。 對於具有相同考慮的每個用戶項目，請使用private,max-age=0 。

我會完全避免使用no-cache ，因為它似乎已被某些瀏覽器和流行的緩存混為一談，使其功能等同於no-store 。

此外，請勿模仿 Akamai 和 Limelight。 雖然他們本質上運行大量緩存陣列作為他們的主要業務，並且應該是專家，但他們實際上有既得利益從他們的網絡下載更多數據。 Google 也可能不是模擬的好選擇。 他們似乎根據資源隨機使用max-age=0或no-cache 。

Answer 5

max-age
    When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate 
its own cache entry, and the client has supplied its own validator in the request, the 
supplied validator might differ from the validator currently stored with the cache entry. 
In this case, the cache MAY use either validator in making its own request without 
affecting semantic transparency. 

    However, the choice of validator might affect performance. The best approach is for the 
intermediate cache to use its own validator when making its request. If the server replies 
with 304 (Not Modified), then the cache can return its now validated copy to the client 
with a 200 (OK) response. If the server replies with a new entity and cache validator, 
however, the intermediate cache can compare the returned validator with the one provided in 
the client's request, using the strong comparison function. If the client's validator is 
equal to the origin server's, then the intermediate cache simply returns 304 (Not 
Modified). Otherwise, it returns the new entity with a 200 (OK) response. 

    If a request includes the no-cache directive, it SHOULD NOT include min-fresh, 
max-stale, or max-age. 

禮貌： http : //www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

不要接受這個作為答案 - 我將不得不閱讀它以了解它的真正用法:)

Answer 6

我算不上是緩存專家，但 Mark Nottingham 是。 這是他的緩存文檔。 他在參考資料部分也有很好的鏈接。

根據我對這些文檔的閱讀，看起來max-age=0可以允許緩存對在“同一時間”傳入的請求發送緩存響應，其中“同時”意味着足夠接近它們看起來同時緩存，但no-cache不會。

Answer 7

順便說一句，值得注意的是，一些移動設備，尤其是像 iPhone/iPad 這樣的蘋果產品，完全忽略了諸如 no-cache、no-store、Expires: 0 之類的標頭，或者其他任何你可能試圖強迫它們不重復使用的標頭。表單頁面。

這讓我們一直頭疼不已，因為我們試圖解決用戶 iPad 的問題，比如在他們通過表單流程到達的頁面上睡着了，比如 3 步中的第 2 步，然后設備完全忽略了商店/緩存指令，據我所知，只是從它的最后狀態獲取頁面的虛擬快照，也就是說，忽略它被明確告知的內容，不僅如此，還獲取不應存儲的頁面，並在沒有實際再次檢查的情況下存儲它，這會導致各種奇怪的 Session 問題，等等。

我只是添加這個以防有人出現並且無法弄清楚為什么他們會遇到特別是iphone和ipad的會話錯誤，這似乎是該領域迄今為止最嚴重的違規者。

我已經對這個問題進行了相當廣泛的調試器測試，這是我的結論，設備完全忽略了這些指令。

即使在常規使用中，我發現有些手機也完全無法通過例如 Expires: 0 檢查新版本，然后檢查上次修改日期以確定是否應該獲得新版本。

它根本沒有發生，所以我被迫做的是將查詢字符串添加到我需要強制更新的 css/js 文件中，這會欺騙愚蠢的移動設備認為它是一個它沒有的文件，例如： .css?v=1，然后 v=2 用於 css/js 更新。 這在很大程度上是有效的。

順便說一句，如果將用戶瀏覽器保留為默認值，截至 2016 年，正如我不斷發現的那樣（我們對我們的網站進行了大量更改和更新）也無法檢查此類文件的上次修改日期，但查詢字符串方法解決了這個問題。 這是我注意到的客戶和辦公室人員，他們傾向於在瀏覽器上使用基本的普通用戶默認值，並且不知道 css/js 等緩存問題，幾乎總是無法獲得新的 css/js 更改，這意味着他們的瀏覽器的默認設置，主要是 MSIE / Firefox，沒有按照他們的要求做，他們忽略更改並忽略上次修改日期並且不驗證，即使明確設置了 Expires: 0。

這是一個很好的線程，提供了很多好的技術信息，但同樣重要的是要注意對這些東西的支持在特別是移動設備中的糟糕程度。 每隔幾個月，我就必須添加更多的保護層，以防止他們未能遵循收到的標頭命令，或正確插入這些命令。

Answer 8

我正在寫一系列文章，深入探討這些主題，恕我直言，顯然開發人員之間的討論不夠。

瀏覽器，私人代理和CDN：
https://medium.com/free-code-camp/http-caching-in-depth-part-1-a853c6af99db

Cache-Control和Vary https://medium.com/@lojacquemin/an-in-depth-introduction-to-http-caching-cache-control-vary-e3229815ddf4

Answer 9

（令人驚訝的是）沒有提到的一件事是，請求可以使用max-stale指令明確指示它將接受陳舊數據。 在這種情況下，如果服務器以max-age=0響應，則緩存將僅考慮響應陳舊，並且可以自由使用它來滿足客戶端的請求 [請求潛在陳舊數據]。 相比之下，如果服務器發送的no-cache確實勝過客戶端（使用max-stale ）對陳舊數據的任何請求，因為緩存必須重新驗證。

Answer 10

區別在於，無緩存（Firefox上無存儲）可防止任何類型的緩存。 這對於防止將包含安全內容的頁面寫入磁盤以及即使應使用“后退”按鈕重新訪問的頁面也應始終進行更新的頁面很有用。

max-age = 0表示高速緩存條目是陳舊的，需要重新驗證，但不阻止高速緩存。 通常，瀏覽器在每個瀏覽器會話中僅驗證一次資源，因此，只有在新會話中訪問該網站后，內容才會更新。

通常，瀏覽器不會刪除過期的緩存條目，除非它們在瀏覽器緩存已滿時為新內容回收空間。 使用no-store，no-cache允許顯式刪除緩存條目。