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

このページの内容は ApigeeApigee ハイブリッドに該当します。

Apigee Edge のドキュメントを表示する。

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

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

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

Cache-Control

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

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

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

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

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

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

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

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

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

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

Expires

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

Expires ヘッダーに使用できる日付形式については、HTTP/1.1 仕様をご覧ください。次に例を示します。

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

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

Expires ヘッダーの詳細については、HTTP/1.1 仕様のヘッダー フィールドの定義をご覧ください。

ETag

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

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

エンティティ タグの詳細については、HTTP/1.1 仕様のプロトコル パラメータをご覧ください。

If-Match

If-Match リクエスト ヘッダーを使用しており、ヘッダー内の ETag がキャッシュされた ETag と一致する場合、キャッシュされたエンティティは現在のエンティティです。If-Match ヘッダーを指定する GET 以外のリクエストは、配信元のキャッシュ機能でリクエストを処理する機会を確保するために、配信元サーバーに渡されます。

If-Match の詳細については、HTTP/1.1 仕様のヘッダー フィールドの定義をご覧ください。

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

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

If-None-Match

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

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

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

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

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

If-Modified-Since

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

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

Accept-Encoding

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

Accept ヘッダー値をキャッシュキーの先頭に付加することで、キャッシュされるアイテムごとに、より意味のあるキーにできます。詳細については、ResponseCache ポリシーの「キャッシュキーの構成」をご覧ください。