問題

從RFC 2616

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

no-cache

如果 no-cache 指令沒有指定 field-name,那麼快取 不得在沒有響應的情況下使用響應來滿足後續請求 使用原始伺服器成功地重新驗證.這允許原點 android – 用於防止快取的伺服器,即使已配置為 返回對客戶端請求的陳舊響應。

因此它指導代理重新驗證所有響應.

相比之下

must-revalidate

當收到的響應中存在must-revalidate指令時 透過快取,快取不必在條目變得陳舊後使用條目 android – 響應後續請求而不首先重新驗證它 原始伺服器

因此它指導代理重新驗證陳舊的響應。

特別是關於no-cache,這是使用者代理實際上如何經驗處理這個指令的?

如果有must-revalidatemax-age,no-cache的重點是什麼?

見本評論:

http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/

no-cache

雖然這個指令聽起來像是指示瀏覽器不要 快取頁面,有一個微妙的區別. “no-cache”指令, 根據RFC,告訴瀏覽器它應該重新驗證 在從快取中提供頁面之前,伺服器.重新驗證是一個 使應用程式保持頻寬的整潔技術。 瀏覽器快取的頁面沒有更改,伺服器只是訊號 這對瀏覽器,頁面從快取顯示.因此, 瀏覽器(至少在理論上)將頁面儲存在其快取中,但 只有在使用伺服器重新驗證後才顯示它.在實踐中,IE Firefox已經開始處理no-cache指令,好像它 指示瀏覽器甚至不要快取頁面.我們開始觀察 一年前的這種行為,我們懷疑這種變化是 由於該指令被廣泛(和不正確)使用 防止快取。

有沒有人有更多的官員?

更新

伺服器應該使用 must-revalidate 指令,如果並且只有在沒有驗證關於表示的請求可能導致不正確的操作,例如默默地未執行的金融事務的情況下。

這是我到目前為止從未注意到的事情. RFC正在說不要輕易使用must-revalidation.問題是,使用Web服務,你必須採取負面的檢視,併為您未知的客戶端應用程式假設最差.任何陳舊資源都有可能導致問題.

另外一些我剛剛考慮過的東西,沒有Last-Modified或ETags,瀏覽器只能再次獲取整個資源.但是,使用ETags,我觀察到Chrome至少似乎在每個請求上重新驗證.這使這兩個指令都沒有實際意義或至少名稱不佳,因為它們無法正確重新驗證,除非請求還包含其他標頭,無論如何導致’始終重新驗證’.

我只想使最後一點更清楚.透過設定must-revalidate,但不包括ETag或Last-Modified,代理只能再次獲得內容,因為它沒有任何東西可以傳送到伺服器進行比較.

但是,我的經驗測試表明,當ETag或修改的頭資料包含在響應中時,代理總是重新驗證,無論must-revalidate頭的存在.

所以must-revalidate的要點是在它過時強制“繞行快取”,這隻有在您設定了一個生命週期/年齡時才會發生,因此如果在沒有年齡或其他標題的響應上設定must-revalidate,它實際上等同於no-cache,因為響應將被認為立即過時.

- 所以我最終要給吉利的答案打個標記吧! --------------------------------------------------------------------------------------------

  最佳答案

我相信must-revalidate意味著“一旦快取過期,即使他們說陳舊的響應是可以接受的,也拒絕向用戶返回陳舊的響應.” Whereas no-cache意味著must-revalidate加上響應立即變得陳舊.

如果響應可以快取10秒,那麼must-revalidate在10秒後啟動,而no-cache在0秒後意味著must-revalidate.

至少,這是我的解釋。

  相同標籤的其他問題

http