Send Docs Feedback

Note: Most user interface tasks can be performed in Edge Classic or the New Edge experience. For an overview, getting started topics, and release notes specific to the New Edge experience, see the docs.

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

このトピックでは、ResponseCache ポリシーの使用時に Edge が HTTP/1.1 キャッシングヘッダーを制御する方法について説明します。Apigee Edge は現在、バックエンドターゲット (送信元) サーバーから受信した HTTP/1.1 キャッシングヘッダーのサブセットおよびディレクティブ (サポート対象外の機能はこのトピックには記載しません) をサポートします。

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

HTTP/1.1 仕様では、標準的なキャッシングヘッダーに加えて、HTTP リクエスト/レスポンスチェーンでキャッシングをサポートする制御メカニズムを規定しています。これらのヘッダーとメカニズムは、キャッシュ対象リソースの情報を提供します。またこれらの情報は、キャッシュされたデータの管理方法をサーバーが決定する際に役立ちます。仕様自体には、HTTP でのキャッシングに関して詳細な情報が含まれています。またインターネットには、HTTP キャッシングについて説明するブログ、記事、その他のリソースが多くあります。
ヘッダーを使用してキャッシュキーおよびキャッシュエントリ TTL を制御する

レスポンスキャッシュキーの構築時、およびキャッシュエントリ TTL の設定時に、Edge ではレスポンスヘッダーを使用することができます。使用する場合は、ResponseCache ポリシーの以下のフラグ要素を使用します。

  • <UseResponseCacheHeaders> -- true に設定すると、キャッシュでレスポンスの「生存期間」(TTL) を設定するときに HTTP レスポンスヘッダーが使用されます。詳細については、「キャッシュエントリの有効期限の設定」および <UseResponseCacheHeaders> (レスポンスキャッシュポリシーの) を参照してください。
  • <UseAcceptHeader>-- trueに設定すると、キャッシュキーを拡張するために、レスポンス Acceptヘッダーが使用されます。詳細については、<UseAcceptHeader> (レスポンスキャッシュポリシーの) を参照してください。
ヘッダー Support
Cache-Control バックエンド送信元サーバーから返されたレスポンスではサポートされますが、クライアントリクエストではサポートされません。Edge はディレクティブのサブセットをサポートします。
Expires サポートされます。上書きできます。
Entity Tags (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 は、Cache-Control レスポンスヘッダー機能 (HTTP/1.1 仕様で定義された) のサブセットをサポートします。以下の内容に注意してください。

  • Apigee Edge は、受信クライアントリクエストで受信した Cache-Control ヘッダーをサポートしません。
  • Apigee Edge は、パブリックキャッシュの概念に適合する対象のみをサポートします。HTTP 仕様では、Cache-Control はパブリック (共有) とプライベート (シングル ユーザー) のどちらでも使用できます。
  • Apigee Edge は、Cache-Control レスポンスディレクティブ (HTTP/1.1 仕様) のサブセットのみをサポートします。詳細については、「Cache-Control レスポンスヘッダーディレクティブのサポート」を参照してください。

Cache-Control レスポンスヘッダーディレクティブのサポート

Apigee は、送信元サーバーからのレスポンスで、HTTP/1.1 仕様のサブセットディレクティブをサポートします。次の表では、HTTP Cache-Control レスポンスヘッダーディレクティブに対して、Apigee Edge でのサポート対応状況について説明します。

ここにリストされたディレクティブの詳細については、Cache-Control (HTTP/1.1 仕様) を参照してください。

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

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

このディレクティブは、s-maxage ディレクティブによって上書きされ、Expires ヘッダーを上書きします。またポリシーの <ExpirySettings> 要素で上書きすることもできます。詳細については、「キャッシュエントリの有効期限の設定」および <UseResponseCacheHeaders> (レスポンスキャッシュポリシーの) を参照してください。

ResponseCache ポリシーでキャッシュされる内容には、送信元で設定された max-age 値が含まれます。つまり、キャッシュから取得されるときに、内容が max-age の指定値よりも古く (クライアント側での認識よりも古く) なる可能性があります。
must-revalidate サポートされません。すべてのキャッシュエントリは、期限切れになると Apigee Edge によってすぐに削除されます。
no-cache

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

HTTP/1.0 ヘッダー Pragma:no-cache は、Cache-Control: no-cache と同じように処理されます。
no-store サポートされません。
no-transform サポートされません。
private サポートされません。このディレクティブを受信すると、送信元のレスポンスはキャッシュされません。フィールド名はすべて無視されます。
proxy-revalidate サポートされません。すべてのキャッシュエントリは、期限切れになると Apigee Edge によってすぐに削除されます。
public 他のディレクティブが別の処理を命令している場合でも、Edge は送信元のレスポンスをキャッシュします。HTTP/1.1 仕様において、このルールの唯一の例外は、レスポンスに Authorization ヘッダーが含まれている場合です。
s-maxage

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

このディレクティブは、max-age ディレクティブと Expires ヘッダーを上書きします。ポリシーの <ExpirySettings> 要素で上書きすることができます。詳細については、「キャッシュエントリの有効期限の設定」および <UseResponseCacheHeaders> (レスポンスキャッシュポリシーの) を参照してください。

ResponseCache ポリシーでキャッシュされる内容には、送信元で設定された s-maxage 値が含まれます。つまり、キャッシュから取得されるときに、内容が s-maxage の指定値よりも古く (クライアント側での認識よりも古く) なる可能性があります。

Expires

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

Cache-Control ヘッダーのディレクティブ max-age および s-maxageExpires ヘッダーよりも優先され、このヘッダーを上書きします。詳細については、「キャッシュエントリの有効期限の設定」および <UseResponseCacheHeaders> (レスポンスキャッシュポリシーの) を参照してください。

Expires ヘッダーの有効な日付形式については、HTTP/1.1 仕様で規定されています。例:

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

HTTP の日時の形式については、「Date/Time Formats」(HTTP/1.1 仕様) を参照してください。

仕様の 14.21 セクションの記述では、それ以降 1 年を超える Expires 値は、キャッシュエントリに有効期限がないと見なすとされています。ただし、Apigee では、このような値は、指定された日時までエントリをキャッシュする必要があると解釈しています。

Expires ヘッダーの詳細については、「Header Field Definitions」(HTTP/1.1 仕様) を参照してください。

ETag

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

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

エンティティタグの詳細については、「Protocol Parameters」(HTTP/1.1 仕様) で確認することができます。

If-Match

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

If-Match の詳細については、「Header Field Definitions」(HTTP/1.1 仕様) で確認することができます。

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

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

If-None-Match

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

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

条件 処理
If-None-Match ヘッダーに 1 つ以上の Etags が指定されている場合
  1. Apigee Edge は、指定された URI のために、有効期限が切れていないキャッシュエントリを取得して、これらのキャッシュエントリの有効度の高い ETags と If-None-Match ヘッダーに指定された値を比較します。
  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

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

Accept ヘッダー値をキャッシュキーに追加して、キャッシュされるアイテムごとに、キー情報を詳細にすることができます。詳細については、「キャッシュキーの構成」(レスポンスキャッシュポリシーの) を参照してください。

Help or comments?