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

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

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

ヘッダー サポート
Cache-Control バックエンド送信元サーバーから返されるレスポンスではサポートされますが、クライアント リクエストではサポートされません。Edge はディレクティブのサブセットをサポートします。
Expires サポートされます。オーバーライドできます。
エンティティ タグ（ETags） 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 プロキシで定義されたターゲット エンドポイントと、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> をご覧ください。

有効期限

ResponseCache ポリシーの UseResponseCacheHeaders フラグが true に設定されている場合、Edge は 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 を付けてレスポンスを Edge に送り返すと、Edge はレスポンスとともに ETag をキャッシュします。

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

If-Match

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

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

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

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

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

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

If-Modified-Since

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

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

Accept-Encoding

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

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