您正在查看 Apigee Edge 說明文件。
前往 Apigee X 說明文件。 info
本主題說明 Edge 在您使用 ResponseCache 政策時，如何處理 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-Since | 在 GET 要求中，即使存在有效的快取項目，標頭也會傳送至原始伺服器。 |
| Accept-Encoding | 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 Cache-Control 回應標頭指示。
如要進一步瞭解這裡列出的指令，請參閱 HTTP/1.1 規格中的 Cache-Control。
| Cache-Control 指令 | Apigee Edge 處理指令的方式 |
cache-extension |
不支援。 |
max-age |
如果 ResponseCache 政策將 這個指令會遭到 |
must-revalidate |
不支援。所有快取項目都會在到期後立即遭到 Apigee Edge 刪除。 |
no-cache |
Edge 會快取原始回應，但必須先透過原始伺服器重新驗證，才能用於滿足後續的用戶端要求。這項規則可讓來源傳回 304 未修改的回應，以便指出應從快取傳回回應，進而節省傳回整個回應所需的處理作業。如果原始伺服器傳回完整回應，就會取代現有的快取項目。系統會忽略任何使用此指令指定的欄位名稱。 |
no-store |
不支援。 |
no-transform |
不支援。 |
private |
不支援。如果收到這個指令，系統就不會快取來源回應。系統會忽略任何欄位名稱。 |
proxy-revalidate |
不支援。所有快取項目都會在到期後立即遭到 Apigee Edge 刪除。 |
public |
即使其他指令指出不應快取，Edge 也會快取來源回應。根據 HTTP/1.1 規格，只有在回應中包含授權標頭時，這項規則才會例外。 |
s-maxage |
如果 ResponseCache 政策將 這個指令會覆寫 |
有效期限
當 ResponseCache 政策中的 UseResponseCacheHeaders 旗標設為 true 時，Edge 可以使用 Expires 標頭來決定快取項目的存留時間 (TTL)。這個標頭會指定回應快取項目在過期後會被視為過時的日期/時間。這個標頭可讓伺服器在傳回快取值時，根據時間戳記傳送信號。
HTTP/1.1 規範說明瞭 Expires 標頭可接受的日期格式。例如：
到期日：1994 年 12 月 1 日星期四 16:00:00 GMT
如要進一步瞭解 HTTP 日期/時間格式，請參閱 HTTP/1.1 規格的「日期/時間格式」一節。
如要進一步瞭解 Expires 標頭，請參閱 HTTP/1.1 規格的「標頭欄位定義」一節。
ETag
實體標記 (ETag) 是與要求的資源相關聯的 ID。伺服器可使用 ETag，判斷要求的資源與相關的快取資源是否相符。舉例來說，如果回應不符合目前快取的內容，伺服器就會重新快取回應。如果 ETag 相符，就會傳回快取的資源。
當目標端點傳送回 Edge 的回應時，Edge 會將 ETag 與回應一併快取。
如要進一步瞭解實體標記，請參閱 HTTP/1.1 規格的「通訊協定參數」一節。
If-Match
使用 If-Match 要求標頭時，如果標頭中的 ETag 與快取的 ETag 相符，則快取的實體即為目前的實體。除了指定 If-Match 標頭的 GET 以外，其他要求都會傳送至來源伺服器，以確保任何來源快取設施都有機會處理要求。
如要進一步瞭解 If-Match，請參閱 HTTP/1.1 規格的「標頭欄位定義」一節。
如果 Edge 收到來自用戶端的傳入 GET 要求，且該要求包含 If-Match 標頭：
| 如果 | 接著 |
|---|---|
If-Match 標頭會指定一或多個 ETag |
|
If-Match 標頭指定「*」 |
要求會傳遞至原始伺服器，確保任何原始快取設施都有機會處理要求 |
| 找到含有相同要求 URI 的快取項目，但只包含弱 ETag | 原始伺服器必須重新驗證項目，才能傳回至用戶端 |
| ETag 來自來源伺服器。 | 系統會將 ETag 原封不動地傳回給用戶端 |
If-None-Match
使用 If-None-Match 標頭時，如果標頭中的 ETag「不相符」快取的 ETag，則快取的實體即為目前實體。除了包含此標頭的 GET 以外，其他要求都會傳送至來源伺服器。
如果 Edge 收到含有以下標頭的內送 GET 要求：
| 如果 | 接著 |
|---|---|
If-None-Match 標頭會指定一或多個 ETag |
|
|
|
Edge 會傳回 304 未修改狀態 |
| 找到具有相同要求 URI 的快取項目，但只包含弱 ETag | Edge 將項目傳回至用戶端前，原始伺服器必須重新驗證該項目 |
| Edge 從來源伺服器接收 ETag | 系統會將 ETag 原封不動地傳回給用戶端 |
If-Modified-Since
如果 Apigee Edge 在 GET 要求中收到 If-Modified-Since 標頭，即使存在有效的快取項目，也會將該標頭傳遞至原始伺服器。
這可確保任何未透過 Apigee Edge 的資源更新都會計算在內。如果原始伺服器傳回新的實體，Edge 會將現有的快取項目替換為新值。如果伺服器傳回 304 未修改狀態，Edge 會傳回回應值，前提是快取回應的 Last-Modified 標頭指出該值未變更。
Accept-Encoding
如果傳入的要求包含標頭 Accept-Encoding，且值為 gzip、deflate 或 compress，原始伺服器會傳回壓縮資料。後續要求不含 Accept-Encoding 標頭時，會預期未經壓縮的回應。Apigee 的回應快取機制可根據傳入的標頭，傳送壓縮和未壓縮的回應，而無須返回原始伺服器。
您可以將 Accept 標頭值附加至快取鍵，讓每個快取項目的鍵更有意義。詳情請參閱「回應快取政策」中的「設定快取鍵」。