要求 Chrome 繞過 XmlHttpRequest 的本地緩存，就像在 Firefox 中一樣？

Question

有些人可能已經知道，對於由 XmlHttpRequest object 發起的請求，Firefox/Chrome 中存在一些緩存問題。 這些問題意味着瀏覽器沒有嚴格遵守規則並且沒有 go 到服務器新的 XSLT 文件（例如）。 響應沒有 Expires header（出於性能原因，我們不能使用它）。

Firefox 在 XHR object“通道”中有附加參數，您將值 Components.interfaces.nsIRequest.LOAD_BYPASS_CACHE 到 Z34D1F91FB2E514B8576FAB1A75A89A6B 到服務器顯式。

Chrome是否存在類似的東西？

讓我立即阻止所有建議添加時間戳作為 GET 參數值或隨機 integer 的人 - 我不希望服務器獲得不同的 URL 請求。 我希望它得到原始的 URL。 原因是我想保護服務器免受對簡單 static 文件的太多不同請求，並在不需要時向客戶端發送太多數據。

如果您使用生成的 GET 參數（如 '?forcenew=12314'）點擊 static 文件（如“？forcenew = 12314”），則對於隨機 integer 的值，每次后續請求都會呈現 200 響應和 304。 如果目標 static 文件與客戶端版本相同，我想發出始終返回 304 的請求。 順便說一句，web 瀏覽器應該如何開箱即用，但 XHR 對象往往不會 go 向服務器詢問文件是否更改。

Answer 1

在我的主要工作項目中，我遇到了同樣的問題。 我的解決方案不是 append 隨機字符串或 GET 請求的時間戳，而是 append GET 請求的特定字符串。

如果你有一個修訂號，例如 subversion 修訂版，或者同樣來自 git/mer 或你正在使用的任何東西，append 。 Static 文件將獲得 304 響應，直到發布新版本。 當新版本發生時，將授予單個 200 響應，然后它又會愉快地生成 304 響應。 :-)

這具有獨立於瀏覽器的額外好處。

如果您不走運並且沒有修訂號，請在每次發布時制作一個並增加它。

Answer 2

您應該查看Etags ，etags 是可以從文件內容生成的鍵，因此一旦服務器上的文件發生更改，系統將是一個新的 etag。 顯然，這將是一個服務端更改，如果您想要一個 200 和隨后的 304，您需要這樣做。 Chrome 和 FF 應該尊重這些 etag，所以你不需要做任何瘋狂的客戶端黑客。

Answer 3

Chrome 現在支持Cache-Control: max-age=0 request HTTP header。 您可以在打開XMLHttpRequest實例后進行設置：

xhr.setRequestHeader( "Cache-Control", "max-age=0" );

這將指示 Chrome 在沒有重新驗證的情況下不使用緩存的響應。

有關更多信息，請查看瀏覽器緩存的 State，由 Mark Nottingham 和RFC 7234 超文本傳輸協議 (HTTP/1.1) 重新訪問：緩存。