您正在查看 Apigee Edge 說明文件。
查看 Apigee X 說明文件。 資訊
本主題說明當您使用 ResponseCache 政策時，Edge 如何處理 HTTP/1.1 快取標頭。Apigee Edge 目前支援部分 HTTP/1.1 快取標頭和指令 (本主題列出不支援的功能)，這些指令會從後端目標 (來源) 伺服器接收。
此外，特定標頭 Edge 也會根據其指令採取行動。在某些情況下，這些 HTTP/1.1 快取標頭會覆寫 ResponseCache 政策中指定的任何行為。
舉例來說，如果後端伺服器傳回 Cache-Control 標頭，您可以讓標頭的 s-maxage 指令覆寫政策中的其他到期時間設定。
| 標題 | 支援 |
|---|---|
| 快取控制 | 支援從後端原始伺服器傳回的回應，但不支援用戶端要求。Edge 支援部分指令， |
| 效期 | 支援。可以覆寫。 |
| 實體標記 (ETag) | If-Match 和 If-None-Match 機制的具體行為。 |
| If-Modified-With | 在 GET 要求中，即使存在有效的快取項目，標頭仍會傳遞至原始伺服器。 |
| 接受-編碼 | Edge 會根據傳入標頭傳送壓縮或未壓縮的回應。 |
Cache-Control
Apigee Edge 僅支援後端來源伺服器傳回的回應 Cache-Control 標頭 (HTTP/1.1 規格允許用戶端要求和來源伺服器回應中的 Cache-Control 標頭)。來源伺服器可包含 Apigee Edge API Proxy 中定義的目標端點，以及使用 TargetServer API 呼叫建立的目標端點。
Cache-Control 支援限制
Apigee Edge 支援 HTTP/1.1 規範中定義的 Cache-Control 回應標頭功能子集。請注意以下事項：
- Apigee Edge 不支援傳入用戶端要求傳送的
Cache-Control標頭。 - Apigee Edge 僅支援公開快取的概念。(根據 HTTP 規格，
Cache-Control可以是公開 (共用) 或私人 (單一使用者)。 - Apigee Edge 僅支援 HTTP/1.1 規範中
Cache-Control回應指令的子集。詳情請參閱支援 Cache-Control 回應標頭指令。
支援 Cache-Control 回應標頭指令
Apigee 支援針對來源伺服器回應提供的 HTTP/1.1 規格子集指令。下表說明 Apigee Edge 對 HTTP 快取控制回應標頭指令的支援。
如要進一步瞭解此處列出的指令，請參閱 HTTP/1.1 規格中的 Cache-Control 一節。
| 快取控制指令 | Apigee Edge 如何處理指令 |
cache-extension |
不支援。 |
max-age |
如果 ResponseCache 政策將
|
must-revalidate |
不支援。所有快取項目到期後，Apigee Edge 就會立即刪除。 |
no-cache |
邊緣會快取來源回應，但必須先透過原始伺服器重新驗證，才能用於滿足任何後續的用戶端要求。這項規則允許來源傳回 304「未修改」回應，以表示應從快取傳回回應，進而儲存傳回完整回應所需的處理程序。如果原始伺服器傳回完整回應，就會取代現有的快取項目。使用這個指令指定的欄位名稱都會遭到忽略。 |
no-store |
不支援。 |
no-transform |
不支援。 |
private |
不支援。如果接收到這個指令，則不會快取來源回應。系統會忽略所有欄位名稱。 |
proxy-revalidate |
不支援。所有快取項目到期後，Apigee Edge 就會立即刪除。 |
public |
即使其他指令另有指示，邊緣也會快取來源回應。根據 HTTP/1.1 規格，當回應包含授權標頭時，這項規則的唯一例外狀況。 |
s-maxage |
如果 ResponseCache 政策將 這個指令會覆寫 |
到期時間：
當 ResponseCache 政策中的 UseResponseCacheHeaders 標記設為 true 時，Edge 可以使用 Expires 標頭決定快取項目的存留時間 (TTL)。這個標頭指定的日期/時間後，系統會將回應的快取項目視為過時。伺服器可透過這個標頭，在可以根據時間戳記傳回快取值的時機發出通知。
如需 Expires 標頭可接受的日期格式說明，請參閱 HTTP/1.1 規格。例如：
到期日：1994 年 12 月 1 日星期四 16:00:00 GMT
如要進一步瞭解 HTTP 日期/時間格式，請參閱 HTTP/1.1 規格中的日期/時間格式。
如要進一步瞭解 Expires 標頭，請參閱 HTTP/1.1 規格中的「標頭欄位定義」一節。
ETag
實體標記 (ETag) 是與要求資源相關聯的 ID。伺服器可以使用 ETag 判斷所要求的資源與相關聯的快取資源是否相符。例如，如果回應與目前快取的內容不符，伺服器可能會重新快取回應。如果 ETag 相符，便可傳回快取的資源。
當目標端點使用 ETag 將回應傳回至 Edge 時，Edge 會快取 ETag 與回應。
如要進一步瞭解實體標記，請參閱 HTTP/1.1 規格中的通訊協定參數。
符合條件
使用 If-Match 要求標頭時，如果標頭中的 ETag 與快取的 ETag 相符，則快取實體為最新版本。凡是指定 If-Match 標頭的 GET 以外的要求都會傳遞至原始伺服器，確保所有來源快取設備都有機會處理要求。
如要進一步瞭解 If-Match，請參閱 HTTP/1.1 規格中的標頭欄位定義。
如果 Edge 收到來自含有 If-Match 標頭的用戶端的傳入 GET 要求：
| 如果 | Then |
|---|---|
If-Match 標頭指定一或多個 ETag |
|
If-Match 標頭指定「*」 |
要求會傳遞至原始伺服器，確保所有來源快取設施都能處理要求 |
| 找到具有相同要求 URI 的快取項目，但其中只包含強度不足的 ETag | 原始伺服器必須先重新驗證項目，才能將項目傳回用戶端 |
| ETag 來自原始伺服器。 | ETag 不會改變給用戶端 |
無相符結果
使用 If-None-Match 標頭時，如果標頭中的 ETag 與快取的 ETag 「不符」，則快取實體為最新版本。針對包含此標頭的 GET 以外的要求都會傳遞至原始伺服器，
如果 Edge 收到具有此標頭的傳入 GET 要求：
| 如果 | Then |
|---|---|
If-None-Match 標頭指定一或多個 ETag |
|
|
|
Edge 傳回「304 未修改」狀態 |
| 找到具有相同要求 URI 的快取項目，但當中只包含強度不足的 ETag | 原始伺服器必須重新驗證項目，Edge 才會將其傳回用戶端 |
| 邊緣從原始伺服器收到 ETag | ETag 不會改變給用戶端 |
上次修改時間
如果 Apigee Edge 在 GET 要求中收到 If-Modified-Since 標頭，即使已有有效的快取項目，也會將其傳遞至原始伺服器。
這能確保未透過 Apigee Edge 通過資源的任何更新都會列入計算。如果原始伺服器傳回新實體，Edge 會以新值取代現有的快取項目。如果伺服器傳回「304 未修改」狀態，如果快取回應的 Last-Modified 標頭指出回應尚未變更，Edge 就會傳回回應值。
接受 - 編碼
如果傳入要求包含標頭 Accept-Encoding 且值為 gzip、deflate 或 compress，來源伺服器就會以壓縮後的資料做出回應。後續要求出現 Accept-Encoding 標頭時，會預期收到未經壓縮的回應。Apigee 的回應快取機制能夠根據傳入標頭，同時傳送已壓縮及未壓縮的回應，而不必回到原始伺服器。
您可以接受附加至快取金鑰的標頭值，讓每個快取項目的金鑰更有意義。詳情請參閱回應快取政策中的「設定快取金鑰」一節。