支援 HTTP 回應標頭

本頁內容適用於 Apigee 和 Apigee Hybrid。

查看 Apigee Edge 說明文件。

本主題說明使用 ResponseCache 政策時，Apigee 如何處理 HTTP/1.1 快取標頭。Apigee 目前支援從後端目標 (來源) 伺服器收到的部分 HTTP/1.1 快取標頭和指令 (不支援的功能列於本主題中)。

此外，Apigee 會根據特定標頭的指令採取行動。在某些情況下，這些 HTTP/1.1 快取標頭會覆寫 ResponseCache 政策中指定的任何行為。舉例來說，如果後端伺服器傳回 Cache-Control 標頭，標頭的 s-maxage 指令可能會覆寫政策中的其他到期設定。

注意：HTTP/1.1 規格說明標準快取標頭和控制機制，這些機制支援 HTTP 要求/回應鏈中的快取功能。這些標頭和機制會提供快取資源的相關資訊。伺服器也會根據這些標頭決定如何管理快取資料。規格本身包含 HTTP 快取的詳細資訊。 網路上也有許多網誌、文章和其他資源，說明 HTTP 快取。

注意： 使用標頭影響快取金鑰和快取項目存留時間：您可以讓 Apigee 在建構回應快取金鑰和設定快取項目存留時間時，使用回應標頭。如要執行這項操作，請使用 ResponseCache 政策的下列旗標元素：

• <UseResponseCacheHeaders> - 設為 true 時，Apigee 會考量設定快取中回應的存留時間 (TTL) 時所用的 HTTP 回應標頭。詳情請參閱「設定快取項目到期時間」和「<UseResponseCacheHeaders>」一節的「回應快取政策」。
• <UseAcceptHeader> -- When this is set to true, Apigee will use response Accept headers to augment the cache key. 詳情請參閱回應快取政策中的 <UseAcceptHeader>。

標頭	支援
快取控制	支援後端原始伺服器傳回的回應，但不支援用戶端要求。 Apigee 支援部分指令。
效期	支援。可覆寫。
實體標記 (ETag)	If-Match 和 If-None-Match 的特定行為。
If-Modified-Since	在 GET 要求中，即使存在有效的快取項目，標頭也會傳遞至原始伺服器。
Accept-Encoding	Apigee 會根據傳入的標頭，傳送壓縮或未壓縮的回應。

Cache-Control

Apigee 僅支援從後端原始伺服器傳回的回應中的 Cache-Control 標頭 (HTTP/1.1 規格允許用戶端要求和原始伺服器回應中的 Cache-Control 標頭)。來源伺服器可以包含 Apigee API Proxy 中定義的目標端點，以及使用 TargetServer API 呼叫建立的端點。

Cache-Control 支援限制

Apigee 支援 HTTP/1.1 規格中定義的Cache-Control回應標頭功能子集。請注意以下事項：

• Apigee 不支援隨傳入用戶端要求抵達的 Cache-Control 標頭。
• Apigee 僅支援公開快取概念。(根據 HTTP 規格，Cache-Control 可以是公開 (共用) 或私密 (單一使用者)。)
• Apigee 僅支援 HTTP/1.1 規格中的部分 Cache-Control 回應指令。詳情請參閱「支援 Cache-Control 回應標頭指令」。

支援 Cache-Control 回應標頭指令

Apigee 支援 HTTP/1.1 規格中，源伺服器回應的指令子集。下表說明 Apigee 支援的 HTTP Cache-Control 回應標頭指令。

如要進一步瞭解這裡列出的指令，請參閱 HTTP/1.1 規格中的「Cache-Control」。

快取控制指令	Apigee 處理指令的方式
cache-extension	不支援。
max-age	如果 ResponseCache 政策將 <UseResponseCacheHeaders> 元素設為 true，系統就會將回應快取這項指令指定的秒數。 這項指令會覆寫 s-maxage 指令，並覆寫 Expires 標頭。政策的 <ExpirySettings> 元素也可以覆寫這項設定。詳情請參閱「設定快取項目到期時間」和「<UseResponseCacheHeaders>」一節的回應快取政策。 注意：透過 ResponseCache 政策快取的內容會保留來源設定的 max-age 值。這表示從快取擷取內容時，內容可能比 max-age 值所建議的舊 (比用戶端所知的舊)。
must-revalidate	不支援。Apigee 會在快取項目過期後立即刪除。
no-cache	Apigee 會快取原始回應，但必須先向原始伺服器重新驗證，才能用於滿足後續的任何用戶端要求。這項規則允許來源傳回 304 Not Modified 回應，指出應從快取傳回回應，因此可節省傳回完整回應所需的處理作業。如果原始伺服器傳回完整的回應，就會取代現有的快取項目。系統會忽略使用這項指令指定的任何欄位名稱。 注意：HTTP/1.0 標頭 Pragma: no-cache 會視為等同於 Cache-Control: no-cache。
no-store	不支援。
no-transform	不支援。
private	不支援。如果收到這項指令，系統就不會快取來源回應。系統會忽略所有欄位名稱。
proxy-revalidate	不支援。Apigee 會在快取項目過期後立即刪除。
public	即使其他指令另有指示，Apigee 仍會快取來源回應。根據 HTTP/1.1 規格，這項規則的唯一例外狀況是回應包含授權標頭。
s-maxage	如果 ResponseCache 政策將 <UseResponseCacheHeaders> 元素設為 true，系統就會將回應快取指定秒數。 這項指令會覆寫 max-age 指令和 Expires 標頭。政策的 <ExpirySettings> 元素可以覆寫這項設定。詳情請參閱「設定快取項目到期時間」和「<UseResponseCacheHeaders>」一節的回應快取政策。 注意：透過 ResponseCache 政策快取的內容會保留來源設定的 s-maxage 值。也就是說，從快取擷取內容時，內容可能比 s-maxage 值所建議的舊 (比用戶端所知的舊)。

有效期限

如果將 ResponseCache 政策中的 UseResponseCacheHeaders 標記設為 true，Apigee 就能使用 Expires 標頭判斷快取項目的存留時間 (TTL)。這個標頭會指定日期/時間，之後回應的快取項目就會視為過時。伺服器可透過這個標頭，根據時間戳記判斷是否可傳回快取值。

注意：Cache-Control 標頭指令 max-age 和 s-maxage 的優先順序高於 Expires 標頭，且會覆寫該標頭。詳情請參閱「設定快取項目到期時間」和「<UseResponseCacheHeaders>」一節的「回應快取政策」。

HTTP/1.1 規格中說明瞭 Expires 標頭可接受的日期格式。例如：

到期日：1994 年 12 月 1 日星期四 16:00:00 GMT

如要進一步瞭解 HTTP 日期/時間格式，請參閱 HTTP/1.1 規格中的「日期/時間格式」。

注意：雖然規格的第 14.21 節指出，Expires 值超過一年表示快取項目永不過期，但 Apigee 會將這類值解讀為項目應快取至指定日期和時間。

如要進一步瞭解 Expires 標頭，請參閱 HTTP/1.1 規格中的「標頭欄位定義」。

ETag

實體標記 (ETag) 是與所要求資源相關聯的 ID。伺服器可使用 ETag 判斷要求的資源和相關聯的快取資源是否相符。舉例來說，如果伺服器發現回應與目前快取內容不符，可能會重新快取回應。如果 ETag 相符，伺服器可能會傳回快取資源。

當目標端點將含有 ETag 的回應傳回給 Apigee 時，Apigee 會將 ETag 連同回應一併快取。

如要進一步瞭解實體標記，請參閱 HTTP/1.1 規格中的通訊協定參數。

If-Match

使用 If-Match 要求標頭時，如果標頭中的 ETag 與快取的 ETag 相符，快取的實體就是最新版本。如果 GET 以外的要求指定 If-Match 標頭，系統會將要求轉送至原始伺服器，確保任何原始快取設施都有機會處理要求。

如要進一步瞭解 If-Match，請參閱 HTTP/1.1 規格中的標頭欄位定義。

如果 Apigee 從用戶端收到包含 If-Match 標頭的傳入 GET 要求：

如果	然後
If-Match 標頭會指定一或多個 ETag	Apigee 會擷取指定資源的所有未過期快取項目，並比較這些快取項目中的任何強 ETag 與 If-Match 標頭中指定的項目。 如果找到相符項目，系統會傳回快取項目。 如果沒有，要求會傳遞至原始伺服器。
If-Match 標頭指定「*」	要求會傳遞至原始伺服器，確保任何原始快取設施都有機會處理要求
系統找到具有相同要求 URI 的快取項目，但其中只包含弱 ETag	項目必須先由原始伺服器重新驗證，才能傳回給用戶端
ETag 來自原始伺服器。	ETag 會原封不動地傳回給用戶端

If-None-Match

使用 If-None-Match 標頭時，如果標頭中的 ETag 與快取 ETag 不符，快取實體就是最新版本。如果要求不是 GET，且包含這個標頭，就會傳遞至原始伺服器。

如果 Apigee 收到含有這個標頭的傳入 GET 要求：

如果	然後
If-None-Match 標頭會指定一或多個 ETag	Apigee 會擷取指定 URI 的所有未過期快取項目，並比較這些快取項目中的所有強 ETag 與 If-None-Match 標頭中指定的 ETag。 如果找到相符項目，Apigee 會傳回 304 Not Modified 狀態。如果找不到相符項目，Apigee 會將要求傳遞至原始伺服器。
If-None-Match 標頭指定「*」，且要求 URI 有未過期的快取項目	Apigee 會傳回 304 Not Modified 狀態
系統找到具有相同要求 URI 的快取項目，但只包含弱 ETags	Apigee 將項目傳回用戶端前，必須先由原始伺服器重新驗證
Apigee 從原始伺服器接收 ETag	ETag 會原封不動地傳回給用戶端

If-Modified-Since

如果 Apigee 在 GET 要求中收到 If-Modified-Since 標頭，即使存在有效的快取項目，系統仍會將該標頭傳遞至原始伺服器。

這可確保系統會將未通過 Apigee 的資源更新納入考量。如果來源伺服器傳回新的實體，Apigee 會以新值取代現有的快取項目。如果伺服器傳回 304 Not Modified 狀態，且快取回應的 Last-Modified 標頭指出回應未變更，Apigee 就會傳回回應值。

Accept-Encoding

如果傳入的要求包含 Accept-Encoding 標頭，且值為 gzip、deflate 或 compress，原始伺服器就會傳回壓縮資料。後續要求若沒有 Accept-Encoding 標頭，系統會預期收到未壓縮的回應。Apigee 的回應快取機制可根據傳入的標頭，傳送壓縮和未壓縮的回應，不必返回原始伺服器。

您可以將 Accept 標頭值附加至快取鍵，讓每個快取項目的鍵更有意義。詳情請參閱回應快取政策中的「設定快取金鑰」。