HTTP レスポンス ヘッダーのサポート

このトピックでは、ResponseCache ポリシーを使用している場合に、Edge が HTTP/1.1 キャッシング ヘッダーを処理する仕組みについて説明します。Apigee Edge は現在、バックエンドのターゲット(送信元)サーバーから受信した HTTP/1.1 キャッシング ヘッダーと、ディレクティブのサブセットをサポートしています(サポートされていない機能はこのトピックで一覧が示されています)。

また、Edge は、特定のヘッダーを受信すると、ディレクティブに応じてアクションを開始します。場合によっては、これらの HTTP/1.1 キャッシュ ヘッダーは、ResponseCache ポリシーで指定された動作をオーバーライドします。たとえば、バックエンド サーバーから Cache-Control ヘッダーが返された場合、ヘッダーの s-maxage ディレクティブによりポリシー内の他の有効期限の設定がオーバーライドされる可能性があります。

ヘッダー サポート
Cache-Control バックエンド送信元サーバーから返されるレスポンスではサポートされますが、クライアント リクエストではサポートされません。Edge はディレクティブのサブセットをサポートします。
Expires サポートされます。オーバーライドできます。
エンティティ タグ(ETag) If-MatchIf-None-Match の特定の動作。
If-Modified-Since GET リクエストでは、有効なキャッシュ エントリが存在している場合でも、ヘッダーは送信元サーバーに渡されます。
Accept-Encoding Edge は受信ヘッダーに応じて、圧縮したレスポンスまたは圧縮していないレスポンスを送信します。

Cache-Control

Apigee Edge は、バックエンド送信元サーバーから返されるレスポンスでのみ Cache-Control ヘッダーをサポートします(HTTP/1.1 仕様では、Cache-Control ヘッダーはクライアント リクエストと送信元サーバー レスポンスの両方で使用できます)。送信元サーバーには、Apigee Edge API プロキシで定義されたターゲット エンドポイントと、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 仕様のサブセット ディレクティブをサポートします。次の表は、HTTP Cache-Control レスポンス ヘッダー ディレクティブに対する Apigee Edge のサポート状況を示しています。

このリストにあるディレクティブの詳細については、HTTP/1.1 仕様の Cache-Control をご覧ください。

Cache-Control ディレクティブ Apigee Edge がディレクティブを処理する方法
cache-extension サポートされていません。
max-age

ResponseCache ポリシーで <UseResponseCacheHeaders> 要素を true に設定している場合、このディレクティブで指定された秒数だけレスポンスをキャッシュできます。

このディレクティブは s-maxage ディレクティブによってオーバーライドされ、Expires ヘッダーをオーバーライドします。また、ポリシーの <ExpirySettings> 要素でオーバーライドすることもできます。詳細については、Response Cache ポリシーの「キャッシュ エントリの有効期限を設定する」と <UseResponseCacheHeaders> をご覧ください。

must-revalidate サポートされていません。すべてのキャッシュ エントリは、期限切れになると Apigee Edge によって直ちに削除されます。
no-cache

Edge は送信元のレスポンスをキャッシュしますが、そのレスポンスは、後続のクライアント リクエストへの対応に使用する前に、送信元サーバーで再検証する必要があります。このルールにより、キャッシュからレスポンスを返す必要があることを示すために送信元は「304 Not Modified」レスポンスを返すことができ、その結果、レスポンス全体を返すのに必要な処理を軽減できます。送信元サーバーが完全なレスポンスを返す場合は、既存のキャッシュ エントリを置換します。このディレクティブに指定されたフィールド名はすべて無視されます。

no-store サポートされていません。
no-transform サポートされていません。
private サポートされていません。このディレクティブを受信した場合、送信元のレスポンスはキャッシュされません。フィールド名はすべて無視されます。
proxy-revalidate サポートされていません。すべてのキャッシュ エントリは、期限切れになると Apigee Edge によって直ちに削除されます。
public 他のディレクティブの指示にかかわらず、Edge は送信元のレスポンスをキャッシュします。HTTP/1.1 仕様では、このルールの例外となるのは、レスポンスに Authorization ヘッダーが含まれている場合のみです。
s-maxage

ResponseCache ポリシーで <UseResponseCacheHeaders> 要素を true に設定している場合、このディレクティブで指定された秒数だけレスポンスをキャッシュできます。

このディレクティブは、max-age ディレクティブと Expires ヘッダーをオーバーライドします。また、ポリシーの <ExpirySettings> 要素でオーバーライドすることもできます。詳細については、Response Cache ポリシーの「キャッシュ エントリの有効期限を設定する」と <UseResponseCacheHeaders> をご覧ください。

Expires

ResponseCache ポリシーの UseResponseCacheHeaders フラグを true に設定すると、Edge は Expires ヘッダーを使用してキャッシュされたエントリの有効期間(TTL)を決定できます。このヘッダーは、レスポンスのキャッシュ エントリが古くなったと見なされる日時を指定します。このヘッダーにより、サーバーはタイムスタンプに基づいて、キャッシュされた値を返せる期限を通知できます。

Expires ヘッダーで許容される日付形式は、HTTP/1.1 仕様に記載されています。次に例を示します。

Expires: Thu, 01 Dec 1994 16:00:00 GMT

HTTP の日時形式の詳細については、HTTP/1.1 仕様の Date/Time Formats をご覧ください。

Expires ヘッダーの詳細については、HTTP/1.1 仕様の Header Field Definitions をご覧ください。

ETag

エンティティ タグ(ETag)は、要求されたリソースに関連付けられる識別子です。サーバーは ETag を使用して、要求されたリソースと、キャッシュされた関連リソースが一致するかどうかを判定できます。たとえば、要求されたリソースが現在キャッシュされているリソースと一致しない場合、サーバーはレスポンスを再度キャッシュできます。ETag が一致した場合、サーバーはキャッシュされたリソースを返すことができます。

ターゲット エンドポイントが ETag を付けてレスポンスを Edge に送り返すと、Edge は ETag をレスポンスとともにキャッシュします。

エンティティ タグの詳細については、HTTP/1.1 仕様の Protocol Parameters で確認できます。

If-Match

If-Match リクエスト ヘッダーを使用している場合、ヘッダー内の ETag がキャッシュされた Etag と一致すれば、キャッシュされたエンティティは現在のエンティティです。If-Match ヘッダーを指定する GET 以外のリクエストは、送信元のすべてのキャッシング機構がリクエストを処理する機会を持てるように、送信元サーバーに渡されます。

If-Match の詳細については、HTTP/1.1 仕様の Header Field Definitions で確認できます。

Edge が If-Match ヘッダーを含む受信 GET リクエストをクライアントから受信した場合:

条件 処理
If-Match ヘッダーに 1 つ以上の Etag が指定されている
  1. Apigee Edge は、指定されたリソースの期限切れでないキャッシュ エントリを取得して、それらのキャッシュ エントリの優先度の高いすべての ETag と If-Match ヘッダーに指定された ETag を比較します。
  2. 一致が見つかった場合、キャッシュ エントリが返されます。
  3. 一致が見つからない場合、リクエストは送信元サーバーに渡されます。
If-Match ヘッダーに "*" が指定されている リクエストは送信元サーバーに渡され、送信元のすべてのキャッシング機構にリクエストを処理する機会が確実に与えられます。
同じリクエスト URI を持つキャッシュ エントリが見つかったが、優先度の低い Etag のみが含まれている エントリをクライアントに返す前に送信元サーバーで再検証する必要があります。
送信元サーバーから ETag を受信した ETag は変更なしでクライアントに返されます。

If-None-Match

If-None-Match ヘッダーを使用していて、ヘッダー内の ETag がキャッシュされた Etag と一致しない場合、キャッシュされたエンティティは現在のエンティティです。このヘッダーを含む GET 以外のリクエストは送信元サーバーに渡されます。

Edge がこのヘッダーを含む受信 GET リクエストを受信した場合:

条件 処理
If-None-Match ヘッダーで 1 つ以上の Etag を指定している
  1. Apigee Edge は、指定された URI の期限切れでないキャッシュ エントリを取得して、それらのキャッシュ エントリの優先度の高いすべての ETag と If-None-Match ヘッダーに指定された ETag を比較します。
  2. 一致が見つかった場合、Edge は「304 Not Modified」ステータスを返します。一致が見つからない場合、Edge は送信元サーバーにリクエストを渡します。

If-None-Match ヘッダーに "*" が指定されており、要求された URI に対して期限切れでないキャッシュ エントリが存在する

Edge は「304 Not Modified」ステータスを返します。
同じリクエスト URI を持つキャッシュ エントリが見つかったが、優先度の低い Etags のみが含まれている Edge がエントリをクライアントに返す前に送信元サーバーで再検証する必要があります。
Edge が送信元サーバーから ETag を受信した ETag は変更なしでクライアントに返されます。

If-Modified-Since

Apigee Edge が GET リクエストで If-Modified-Since ヘッダーを受信した場合、有効なキャッシュ エントリが存在していても、ヘッダーは送信元サーバーに渡されます。

これにより、Apigee Edge を通過しなかったリソースに対するすべての更新が確実に処理されます。送信元サーバーが新しいエンティティを返す場合、Edge は既存のキャッシュ エントリを新しい値に置換します。サーバーが「304 Not Modified」ステータスを返した場合、キャッシュされたレスポンスの Last-Modified ヘッダーでレスポンスが変更されていないことが示されていれば、Edge はレスポンス値を返します。

Accept-Encoding

受信リクエストに gzipdeflatecompress のいずれかの値を持つ Accept-Encoding ヘッダーが含まれている場合、送信元サーバーは圧縮されたデータで応答します。後続のリクエストが Accept-Encoding ヘッダーなしで届いた場合、期待されているのは圧縮されていないレスポンスです。Apigee のレスポンス キャッシング メカニズムでは、送信元サーバーに戻ることなく、受信ヘッダーに応じて、圧縮したレスポンスと圧縮していないレスポンスの両方を送信できます。

Accept ヘッダー値がキャッシュキーに追加されるように設定することで、キャッシュされるアイテムごとにキー情報を拡張できます。詳細については、Response Cache ポリシーの「キャッシュキーを構成する」をご覧ください。