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

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

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

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

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

注: ヘッダーを使用してキャッシュキーとキャッシュエントリの TTL に影響を与える: Apigee では、レスポンスキャッシュキーの構成とキャッシュエントリの TTL の設定時にレスポンスヘッダーを使用できます。これを行うには、ResponseCache ポリシーの次のフラグ要素を使用します。

<UseResponseCacheHeaders> -- これが true に設定されている場合、Apigee は、キャッシュ内のレスポンスの「有効期間」（TTL）を設定する際に使用する HTTP レスポンスヘッダーを考慮します。詳細については、ResponseCache ポリシーの「キャッシュエントリの有効期限の設定」と <UseResponseCacheHeaders> をご覧ください。
<UseAcceptHeader> -- これが true に設定されている場合、Apigee はレスポンス Accept ヘッダーを使用してキャッシュキーを拡張します。詳細については、ResponseCache ポリシーの <UseAcceptHeader> をご覧ください。

ヘッダー	サポート
Cache-Control	バックエンド配信元サーバーから返されるレスポンスではサポートされますが、クライアントリクエストではサポートされていません。Apigee はディレクティブのサブセットをサポートします。
Expires	サポートされています。オーバーライドできます
エンティティタグ（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 プロキシで定義されたターゲットエンドポイントと、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>` をご覧ください。注: 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 仕様では、このルールの例外となるのは、レスポンスに Authorization ヘッダーが含まれている場合のみです。
`s-maxage`	ResponseCache ポリシーで `<UseResponseCacheHeaders>` 要素が `true` に設定されている場合、このディレクティブで指定された秒数の間、レスポンスがキャッシュに保存されます。このディレクティブは、`max-age` ディレクティブと `Expires` ヘッダーをオーバーライドします。ポリシーの `<ExpirySettings>` 要素でオーバーライドできます。詳細については、ResponseCache ポリシーの「キャッシュエントリの有効期限の設定」と `<UseResponseCacheHeaders>` をご覧ください。注: ResponseCache ポリシーでキャッシュされる内容には、送信元で設定された s-maxage 値が含まれます。つまり、キャッシュから取得されるときに、内容が s-maxage の指定値よりも古く（クライアント側での認識よりも古く）なる可能性があります。

Expires

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

注: Cache-Control ヘッダーディレクティブ max-age と s-maxage は、Expires ヘッダーより優先されます。詳細については、ResponseCache ポリシーの「キャッシュエントリの有効期限の設定」と <UseResponseCacheHeaders> をご覧ください。

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

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

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

注: 仕様のセクション 14.21 では、1 年を超える Expires 値は、キャッシュエントリが期限切れにならないことを意味するとされていますが、Apigee でのそのような値は、指定された日時まではそのエントリがキャッシュに保存される必要があることを意味すると解釈されます。

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

If-None-Match

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

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

条件	処理
`If-None-Match` ヘッダーで 1 つ以上の ETag が指定されている	Apigee は、指定された URI に対して期限切れでないキャッシュエントリを取得して、キャッシュされたエントリで優先度の高い ETag と `If-None-Match` ヘッダーで指定された ETag を比較します。一致が見つかった場合、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

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

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