1.前言
服務器端 Web 資源緩存的想法是在客戶端和上游之間設置一個組件來緩存先前計算的結果，以避免后者過載。根據您的基礎架構和要求，此組件可以是反向代理或 API 網關。HTTP 提供Cache-Control標頭來自定義緩存的不同方面，例如，服務器在認為資源過時之前將其保存在緩存中的時間。我在上面的文章中使用了插件配置，但您也可以委托給Cache-Control。
關于超文本傳輸??協議 (HTTP) 字段名稱注冊表項目的規范，詳見鏈接：超文本傳輸??協議 (HTTP) 字段名稱注冊表-2024-02-16更新
2.問題
想象一下以下場景。你請求一個資源，例如，GET /blog并得到如下結果：
HTTP/1.1 200 OK
Content-Type: application/json{"id": 1,"title": "CSDN"
}
請求成功；結果被緩存。現在，我請求相同的資源，但由于我的代碼是圍繞 XML 工作的，因此我將標Accept頭設置為application/xml。不幸的是，服務器返回緩存的 JSON 資源，這與我要求的不同，可能會完全破壞我的代碼。
問題是，緩存鍵默認只有一個維度，即 URL。
2.解決方案
我們需要一個可配置的多維緩存鍵。您現在可能已經猜到了，這就是標Vary頭的作用：它明確列出緩存鍵的所有維度。在上面的示例中，上游將使用以下內容傳達附加緩存鍵：
HTTP/1.1 200 OK
Content-Type: application/json
Content-Language: en
Vary: Accept{"id": 1,"title": "CSDN"
}
我們現在不再為每個 URL 設置一個緩存條目，而是為每個 MIME 類型/URL 組合設置一個緩存條目。請注意，是否使用此信息取決于緩存組件。
另一個常見的請求標頭是Accept-Encoding，它通常指定客戶端可以接受哪些壓縮算法。編碼是另一個可能的緩存鍵。規范允許指定多個緩存鍵：
HTTP/1.1 200 OK
Content-Type: application/json
Content-Language: en
Vary: Accept, Accept-Encoding{"id": 1,"title": "CSDN"
}
)
)
