如何使任意 URL 的緩存失效？

Question

根據http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10 ，客戶端必須在 POST、PUT 或 DELETE 請求后使與 URL 關聯的緩存無效。

是否可以指示 web 瀏覽器使任意 URL 的緩存無效，而不向其發出 HTTP 請求？

例如：

1. PUT /companies/Nintendo創建一個名為“Nintendo”的新公司
2. GET /companies列出所有公司
3. 每次創建新公司時，我都想使與GET /companies關聯的緩存無效。 瀏覽器不會自動執行此操作，因為兩者在不同的 URL 上運行。

Cache-Control機制是否不適合這種情況？ 我應該將no-cache與ETag一起使用嗎？ 這種情況的最佳做法是什么？

我知道我可以在下次GET /companies時傳遞no-cache ，但這需要應用程序跟蹤 URL 失效而不是將責任推給瀏覽器。 意思是，我想在步驟 1 之后使 URL 無效，而不是必須保留此信息並在步驟 2 應用它。有什么想法嗎？

Answer 1

是的，您可以（在同一域內）。 從這個答案（稍微釋義）：

在響應 PUT 或 POST 請求時，如果 Content-Location header URI 與請求 URI 不同，則 Content-Location URI 的緩存無效。

因此，在您的情況下，包括Content-Location: /companies header 以響應您的 POST 請求。 這將使瀏覽器的/companies緩存版本失效。

請注意，這不適用於 GET 請求。

Answer 2

不，在 HTTP/1.1 中，您只能在響應對該資源的請求時使客戶端的資源緩存無效。 它可能響應PUT 、 POST或DELETE而不是GET （有關詳細信息，請參閱RFC 7234 第 4.4 節）。

如果您的資源需要客戶端確認他們擁有最新版本，那么no-cache和實體標簽是理想的解決方案。

HTTP/2 允許推送緩存清除（ HTTP/2 的九件事4. 緩存推送）。

Answer 3

在您提供的“使實體無效”的鏈接中，緩存將從其存儲中刪除該實體的所有實例，或者將這些實例標記為“無效”並需要強制重新驗證才能被響應后續請求而返回。”。 現在的問題是緩存在哪里？ 我相信文章所談論的緩存是服務器緩存。

我曾在 VC++ 中從事過一個項目，每當模型更改時，緩存就會更新。 有一個編程邏輯實現來實現這一點。 您提到的文章正確地說“HTTP 協議無法保證所有此類緩存條目都標記為無效” HTTP 協議無法自行使緩存無效。

在我們的項目示例中，我們使用了發布訂閱機制。 當更新/插入 A 類對象時，它也會發布到總線。 控制器注冊以偵聽總線上的對象。 假設一個控制器對對象 A 的變化感興趣，它不會在對象類型 B 發生變化和發布時被回調。 當對象類型 A 確實被更改並發布時，控制器 A 偵聽器函數會使用對象 A 的最新更改更新緩存。 GET /公司的后續請求將從緩存中獲取最新信息。 現在，更改對象 A 和使用最新更改刷新 Cache 之間存在時間間隔。 為了避免在這段時間內發生錯誤，在對象 A 更改之前將對象標記為臟對象。 因此，在這些時間之間發出的請求將等待臟標志被清除。

還有一個瀏覽器緩存。 我記得 ETAGS 用於驗證這一點。 ETAG 是資源的校驗和。 對於這個客戶端應該以某種方式保持舊的 ETAG 值。 如果資源的校驗和已更改，則發送帶有 HTTP 200 的新資源，否則發送 HTTP 304（使用本地副本）。

[更新]

PUT /公司/任天堂

獲取/公司

是兩種不同的資源。 當執行 PUT /companies/Nintendo 請求時，您的 /companies/Nintendo 緩存只會更新，而不是 /companies（我說的是客戶端緩存）。 假設您下次調用GET /companies/Nintendo ，根據 http 標頭返回響應。 GET /companies是一個全新的請求，因為它指向不同的資源。

現在的問題是 http 標頭應該是什么？ 它純粹是特定於應用程序的。 假設它是我不會緩存的股票報價。 假設它是我會緩存一段時間的新聞項目。 您的參考鏈接http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html包含緩存 http 標頭的所有詳細信息。 唯一沒有提到的就是 ETag 的使用。 ETag 可以有資源的校驗和。 檢查http://en.wikipedia.org/wiki/HTTP_ETag並檢查https://devcenter.heroku.com/articles/increasing-application-performance-with-http-cache-headers