Citrix ADC

クッキー、ヘッダー、ポーリングの設定

このトピックでは、cookie、HTTP ヘッダー、およびオリジンサーバーのポーリングを管理するキャッシュを構成する方法について説明します。これには、キャッシュが文書化された標準と異なるデフォルトの動作の変更、キャッシュ可能なコンテンツがキャッシュに格納されない可能性がある HTTP ヘッダーのオーバーライド、更新されたコンテンツのオリジンに対して常にポーリングするようにキャッシュの構成が含まれます。

標準からのキャッシュ動作の分散

デフォルトでは、統合キャッシュは次の RFC 標準に準拠しています。

  • RFC 2616,「HTTP HTTP/1.1」
  • RFC 2617「HTTP 認証:基本およびダイジェストアクセス認証」に記載されているキャッシュ動作
  • RFC 2965「HTTP 状態管理メカニズム」に記載されているキャッシュ動作

組み込みポリシーと Default コンテンツグループ属性により、これらの標準の大部分への準拠が保証されます。

デフォルトの統合キャッシュ動作は、次のように仕様と異なるものです。

  • Bary ヘッダーのサポートは限られています。デフォルトでは、Vary ヘッダーを含む応答は、圧縮されていない限り、キャッシュ不可能とみなされます。圧縮された応答には、コンテンツエンコーディング:gzip、コンテンツエンコーディング:deflate、またはコンテンツエンコーディング:pack200-gzip が含まれ、それに Bary: Accept-Encoding ヘッダーが含まれていてもキャッシュ可能です。
  • 統合キャッシュは、ヘッダーキャッシュ制御の値を無視します。キャッシュなしおよびキャッシュ制御:プライベート。たとえば、キャッシュ制御:no-cache= “set-cookie” を含む応答は、応答にキャッシュ制御:no-cache が含まれているかのように処理されます。デフォルトでは、応答はキャッシュされません。
  • イメージ (content-type = image/*) は、イメージ応答に set-cookie または set-cookie2 ヘッダーが含まれている場合や、イメージ要求に cookie ヘッダーが含まれている場合でも、常にキャッシュ可能と見なされます。統合キャッシュは、キャッシュする前に、応答からset-cookieとset-cookie2ヘッダーを削除します。これはRFC 2965から発散します。RFC 準拠の動作は、次のように設定できます。
add cache policy rfc_compliant_images_policy -rule "http.res.header.set-cookie2.exists || http.res.header.set-cookie.exists" -action NOCACHE


bind cache global rfc_compliant_images_policy -priority 100 -type REQ_OVERRIDE
  • 要求内の次のキャッシュ制御ヘッダーは、RFC 準拠のキャッシュがオリジンサーバーからキャッシュされた応答をリロードするように強制します。

Cache-control: max-age=0

Cache-control: no-cache

サービス拒否攻撃を防ぐため、この動作はデフォルトではありません。

  • デフォルトでは、キャッシュモジュールは、応答ヘッダーの状態がない限り、応答をキャッシュ可能であるとみなします。この動作を RFC 2616 に準拠-weakPosRelExpiry するには、すべてのコンテンツグループに対して-weakNegResExpiry とを 0 に設定します。

レスポンスからクッキーを削除する

クッキーはユーザー向けにパーソナライズされることが多く、通常はキャッシュしないでください。Remove Response Cookies パラメータは、レスポンスをキャッシュする前にSet-Cookie and Set-Cookie2 ヘッダーを削除します。デフォルトでは、コンテンツグループのRemove Response Cookies オプションは、Set-Cookie またはSet-Cookie2 ヘッダーによる応答のキャッシュを禁止します。

注: イメージがキャッシュされている場合、組み込みの動作は、コンテンツグループの構成に関係なく、キャッシュする前にSet-CookieおよびSet-Cookie2ヘッダーを削除することです。

画像など、埋め込まれたレスポンスを格納するすべてのコンテンツグループに対して、デフォルトRemove Response Cookies を受け入れることをお勧めします。

コマンドラインインターフェイスを使用してコンテンツグループのRemove Response Cookiesを構成するには、次の手順を実行します。

コマンドプロンプトで、次のように入力します。

set cache contentgroup <name> -removeCookies YES

  1. [最適化] > [統合キャッシュ] > [コンテンツグループ] に移動し、コンテンツグループを選択します。
  2. [その他] タブの [設定] グループで、[レスポンス Cookie を削除する] オプションを選択します。

応答時にHTTPヘッダーを挿入する

統合キャッシュは、キャッシュヒットに起因する応答に HTTP ヘッダーを挿入できます。Citrix ADCアプライアンスは、キャッシュミスによる応答のヘッダーを変更しません。

次の表は、応答に挿入できるヘッダーの説明です。

ヘッダー 仕様
Age 応答がオリジンサーバーで生成された時点から計算された、応答の経過時間を秒単位で示します。デフォルトでは、キャッシュは、キャッシュから提供されるすべてのレスポンスに対して Age ヘッダーを挿入します。
via 要求または応答の開始ポイントと終了ポイント間のプロトコルと受信者を一覧表示します。Citrix ADCアプライアンスは、キャッシュから配信されるすべての応答にViaヘッダーを挿入します。挿入されるヘッダーのデフォルト値は「NS-CACHE-9.2:Citrix ADC IPアドレスの最後のオクテット」です。詳細は、「キャッシュ用のグローバル属性の構成」を参照してください。
ETag キャッシュは、Last-Modified ヘッダーと ETag ヘッダーを使用して応答の検証をサポートし、応答が古くなっているかどうかを判断します。キャッシュは、応答をキャッシュし、オリジンサーバーが独自のETagヘッダーを挿入していない場合にのみ、応答にETagを挿入します。ETag 値は任意の一意の番号です。応答の ETag 値は、元のサーバーから更新されると変更されますが、サーバーが 304 (オブジェクトが更新されない) 応答を送信しても変わりません。動的コンテンツはキャッシュ不可能と見なされるため、オリジンサーバーは動的コンテンツのバリデータを生成しません。この動作は上書きできます。ETagヘッダー挿入では、キャッシュは完全な応答を提供しないことが許可されています。代わりに、ユーザーエージェントは、統合キャッシュによって最初に送信された動的応答をキャッシュする必要があります。ユーザーエージェントが応答をキャッシュするように強制するには、ETag ヘッダーを挿入し、オリジン提供の Cache-Control ヘッダーを置き換えるように統合キャッシュを構成します。
Cache-Control Citrix ADCアプライアンスは、通常、オリジンサーバーからの応答のキャッシュ可能性ヘッダーを変更しません。オリジンサーバーがキャッシュ不可能とラベル付けされたレスポンスを送信する場合、Citrix ADCアプライアンスがレスポンスをキャッシュしていても、クライアントはレスポンスをキャッシュ不可能として扱います。ユーザーエージェントで動的応答をキャッシュするには、オリジンサーバーの Cache-Control ヘッダーを置き換えることができます。これは、ユーザーエージェントやその他の介在キャッシュにのみ適用されます。統合キャッシュには影響しません。
ヘッダー 仕様
Age 応答がオリジンサーバーで生成された時点から計算された、応答の経過時間を秒単位で示します。デフォルトでは、キャッシュは、キャッシュから提供されるすべてのレスポンスに対して Age ヘッダーを挿入します。
via 要求または応答の開始ポイントと終了ポイント間のプロトコルと受信者を一覧表示します。Citrix ADCアプライアンスは、キャッシュから配信されるすべての応答にViaヘッダーを挿入します。挿入されるヘッダーのデフォルト値は「NS-CACHE-9.2:Citrix ADC IPアドレスの最後のオクテット」です。詳細は、「キャッシュ用のグローバル属性の構成」を参照してください。
ETag キャッシュは、Last-Modified ヘッダーと ETag ヘッダーを使用して応答の検証をサポートし、応答が古くなっているかどうかを判断します。キャッシュは、応答をキャッシュし、オリジンサーバーが独自のETagヘッダーを挿入していない場合にのみ、応答にETagを挿入します。ETag 値は任意の一意の番号です。応答の ETag 値は、元のサーバーから更新されると変更されますが、サーバーが 304 (オブジェクトが更新されない) 応答を送信しても変わりません。動的コンテンツはキャッシュ不可能と見なされるため、オリジンサーバーは動的コンテンツのバリデータを生成しません。この動作は上書きできます。ETagヘッダー挿入では、キャッシュは完全な応答を提供しないことが許可されています。代わりに、ユーザーエージェントは、統合キャッシュによって最初に送信された動的応答をキャッシュする必要があります。ユーザーエージェントが応答をキャッシュするように強制するには、ETag ヘッダーを挿入し、オリジン提供の Cache-Control ヘッダーを置き換えるように統合キャッシュを構成します。
Cache-Control Citrix ADCアプライアンスは、通常、オリジンサーバーからの応答のキャッシュ可能性ヘッダーを変更しません。オリジンサーバーがキャッシュ不可能とラベル付けされたレスポンスを送信する場合、Citrix ADCアプライアンスがレスポンスをキャッシュしていても、クライアントはレスポンスをキャッシュ不可能として扱います。ユーザーエージェントで動的応答をキャッシュするには、オリジンサーバーの Cache-Control ヘッダーを置き換えることができます。これは、ユーザーエージェントやその他の介在キャッシュにのみ適用されます。統合キャッシュには影響しません。

Age、via、またはETagヘッダーを挿入する

次の手順では、Age ヘッダー、Via ヘッダー、ETag ヘッダーを挿入する方法について説明します。

Citrix ADCコマンドインターフェイスを使用して、Age、Via、またはEtagヘッダーを挿入します

コマンドプロンプトで、次のように入力します。

set cache contentgroup <name> -insertVia YES -insertAge YES -insertETag YES

Citrix ADC GUIを使用して経過時間、経由、またはETAGヘッダーを構成する

  1. [最適化] > [統合キャッシュ] > [コンテンツグループ] に移動し、コンテンツグループを選択します。
  2. [その他] タブの [HTTP ヘッダーの挿入] グループで、必要に応じて [経由]、[経過時間]、または [ETag] オプションを選択します。
  3. その他のヘッダータイプの値は自動的に計算されます。Via 値は、キャッシュのメイン設定で設定します。

    HTTP ヘッダーの挿入を設定する

キャッシュコントロールヘッダーを挿入する

統合キャッシュが、オリジンサーバーが挿入した Cache-Control ヘッダーを置き換えると、Expires ヘッダーも置き換えられます。新しい Expires ヘッダーには、過去の有効期限が含まれています。これにより、HTTP/1.0 クライアントとキャッシュ (Cache-Control ヘッダーを認識しない) がコンテンツをキャッシュしないようにします。

Citrix ADC コマンドインターフェイスを使用してキャッシュ制御ヘッダーを挿入する

コマンドプロンプトで、次のように入力します。

set cache contentgroup <name> -cacheControl <value>

Citrix ADC GUIを使用してキャッシュ制御ヘッダーを挿入する

  1. [最適化] > [統合キャッシュ] > [コンテンツグループ] に移動し、
    1. [有効期限方法] タブをクリックし、ヒューリスティックおよびデフォルトの有効期限設定をクリアし、[次の後にコンテンツを期限切れにする] テキストボックスで関連する値を設定します。
    2. その他 」タブをクリックし、挿入するヘッダを「キャッシュ制御」テキストボックスに入力します。または、[Configure] をクリックして、キャッシュされたレスポンスのキャッシュ制御ディレクティブを設定します。

リクエストのキャッシュ制御ヘッダーとプラグマヘッダーを無視する

デフォルトでは、キャッシュモジュールは Cache-Control および Pragma ヘッダーを処理します。キャッシュ制御ヘッダー内の次のトークンは、RFC 2616 で説明されているように処理されます。

  • max-age
  • max-stale
  • only-if-cached
  • no-cache

リクエスト内のPragma: no-cacheヘッダーは、Cache-Control: no-cacheヘッダーと同じように扱われます。

Cache-ControlおよびPragmaヘッダーを無視するようにキャッシュ・モジュールを構成する場合、Cache-Control:No-Cacheヘッダーを含む要求により、Citrix ADCアプライアンスはオリジナル・サーバーからレスポンスを取得しますが、キャッシュされたレスポンスは更新されません。キャッシュモジュールがCache-ControlおよびPragmaヘッダーを処理する場合、キャッシュされた応答がリフレッシュされます。

次の表は、これらのヘッダーのさまざまな設定と、[ブラウザのリロード要求を無視] 設定の影響をまとめたものです。

Cache-ControlおよびPragmaヘッダーを無視する設定 ブラウザのリロード要求を無視する設定 出力
はい [はい] または [いいえ] Cache-Control: no-cacheディレクティブを含め、Cache-ControlおよびPragmaヘッダーを無視します。
いいえ はい Cache-Control:no-cacheヘッダーはキャッシュミスを生成しますが、すでにキャッシュにある応答はリフレッシュされません。
いいえ いいえ Cache-Control: no-cache ヘッダーを含む要求は、キャッシュミスを引き起こし、格納された応答がリフレッシュされます。

コマンドラインインターフェイスを使用してリクエストのキャッシュコントロールヘッダーとプラグマヘッダーを無視するには

コマンドプロンプトで、次のように入力します。

set cache contentgroup <name> -ignoreReqCachingHdrs YES

コマンドラインインターフェイスを使用してブラウザのリロード要求を無視するには

コマンドプロンプトで、次のように入力します。

set cache contentgroup <name> -ignoreReloadReq NO

注: デフォルトでは、-ignoreReloadReq パラメータは YES に設定されています。

GUI を使用してリクエスト内のキャッシュ制御ヘッダーとプラグマヘッダーを無視する

  1. [最適化] > [統合キャッシュ] > [コンテンツグループ] に移動し、コンテンツグループを選択します。
  2. [その他] タブの [設定] グループで、[要求のキャッシュコントロールおよびプラグマヘッダーを無視 する] オプションを選択します。

    キャッシュ制御ヘッダーとプラグマヘッダーを設定する

キャッシュ制御ヘッダーを無視するポリシーの例:

次の例では、応答の Cache-Control ヘッダーに関係なく、Content-type: image/* を含む応答をキャッシュするように、要求時間の上書きポリシーを設定します。

image/* を使用してすべての応答をキャッシュするように要求時間上書きポリシーを設定するには

[すべて無効化] オプションを使用してキャッシュをフラッシュします。

新しいキャッシュポリシーを構成し、ポリシーを特定のコンテンツグループに誘導します。詳細は、「統合キャッシュでのポリシーの構成」を参照してください。

ポリシーが使用するコンテンツグループが、「要求内のキャッシュコントロールヘッダーとプラグマヘッダーの無視」の説明に従って、Cache-Control ヘッダーを無視するように構成されていることを確認します。

ポリシーをリクエスト時間上書きポリシーバンクにバインドします。

詳細については、統合キャッシュポリシーのグローバルバインドを参照してください。

要求が受信されるたびにオリジンサーバーをポーリングする

Citrix ADCアプライアンスは、保存された応答を提供する前に、常にオリジンサーバーを参照するように構成できます。これは、毎回ポーリング(PET)として知られています。Citrix ADCアプライアンスがオリジナル・サーバーを参照し、PET応答の有効期限が切れていない場合、オリジナル・サーバーからの完全な応答によってキャッシュされたコンテンツは上書きされません。このプロパティは、クライアント固有のコンテンツを提供するときに便利です。

PET応答の有効期限が切れた後、Citrix ADCアプライアンスは最初の完全応答がオリジンサーバーから到着したときにPET応答を更新します。

毎回ポーリング (PET) 機能は次のように動作します。

ETagまたはLast-Modifiedヘッダーの形式のバリデータを持つキャッシュされたレスポンスの場合、レスポンスが期限切れになると、自動的にPETとマークされ、キャッシュされます。

コンテンツグループの PET を設定できます。

コンテンツグループを PET として設定すると、コンテンツグループ内のすべての応答に PET とマークされます。PET コンテンツグループは、バリデーターを持たないレスポンスを保存できます。自動的にPETとマークされた回答は、常に期限切れになります。PET コンテンツグループに属する応答は、コンテンツグループの構成方法に基づいて、遅延後に期限切れになる場合があります。

ポーリングでは、次の 2 種類の要求が影響を受けます。

  • 条件付きリクエスト:クライアントは、それが持っている応答が最新のコピーであることを確認するために、条件付きリクエストを発行します。キャッシュされた PET 応答に対するユーザーエージェント要求は、常に条件付き要求に変換され、オリジンサーバーに送信されます。条件付きリクエストには、If-Modified-Since ヘッダーまたは If-None-Match ヘッダーにバリデータがあります。If-Modified-以来、ヘッダは、最終変更ヘッダからの時間が含まれています。If-None-Matchヘッダーには、レスポンスのETagヘッダー値が含まれています。クライアントの応答のコピーが新しい場合、オリジンサーバーは 304 Not Modified と応答します。コピーが古い場合、条件付き応答では、応答全体を含む 200 OK が生成されます。
  • 非条件要求:非条件要求では、応答全体を含む200個のOKしか生成できません。
オリジン・サーバー・レスポンス 操作(アクション)
完全な回答を送信 オリジンサーバーは、応答をそのままクライアントに送信します。キャッシュされたレスポンスの有効期限が切れている場合は、リフレッシュされます。
304 変更されていません 304 応答の次のヘッダー値は、キャッシュされた応答とマージされ、キャッシュされた応答がクライアントに提供されます。日付、有効期限、年齢、キャッシュ制御ヘッダー Max-Age、および S-Maxage トークン
401 無許可、400 不正な要求、405 メソッドは許可されていません。406 は受け入れられません。407 プロキシ認証が必要です。 オリジンの応答はそのままクライアントに提供されます。キャッシュされた応答は変更されません。
その他のエラー応答(404 Not Found など) オリジンの応答はそのままクライアントに提供されます。キャッシュされた応答が削除されます。

注: Poll Every Timeパラメータでは、影響を受ける応答が保存不可能として扱われます。

コマンドラインインターフェイスを使用して毎回ポーリングを構成するには

コマンドプロンプトで、次のように入力します。

add cache contentgroup <contentGroupName> -pollEveryTime YES

GUI を使用したポーリング

  1. [最適化] > [統合キャッシュ] > [コンテンツグループ] に移動し、コンテンツグループを選択します。
  2. [その他] タブの [設定] グループで、[毎回ポーリング (キャッシュされたコンテンツをリクエストごとにオリジンで検証)] オプションを選択します。

    コンテンツグループポーリング設定

PETおよびクライアント固有のコンテンツ

PET機能を使用すると、クライアント向けにコンテンツをカスタマイズできます。たとえば、複数の言語でコンテンツを提供している Web サイトでは、Accept-Language リクエストヘッダーを調べて、提供しているコンテンツの言語を選択します。英語が主な言語である多言語の Web サイトでは、すべての英語のコンテンツを PET コンテンツグループにキャッシュできます。これにより、すべてのリクエストがオリジンサーバーに送信され、レスポンスの言語が決定されます。応答が英語で、コンテンツが変更されていない場合、オリジンサーバーは 304 Not Modified をキャッシュに提供できます。

次の例は、PET コンテンツグループに英語の応答をキャッシュし、キャッシュ内の英語の応答を識別する名前付き式を設定し、このコンテンツグループと名前付き式を使用するポリシーを設定するコマンドを示しています。太字は強調のために使用されます:

add cache contentgroup EnglishLanguageGroup -pollEveryTime YES
add expression containsENExpression –rule "http.res.header(\\"Content-Language\\").contains(\\"en\\")"
add cache policy englishPolicy -rule containsENExpression -action CACHE -storeInGroup englishLanguageGroup
bind cache policy englishPolicy -priority 100 -precedeDefRules NO

PET および認証、承認、監査

Outlook Web アクセス (OWA) は、動的に生成されたコンテンツの PET の利点の良い例です。すべてのメール応答(*.EMLオブジェクト)には、PET応答として保存できるETagバリデータがあります。

メールレスポンスのすべてのリクエストは、レスポンスがキャッシュされていても、オリジンサーバーに送信されます。オリジンサーバーは、リクエスタが認証および認可されているかどうかを決定します。また、応答がオリジンサーバーに存在することを確認します。すべての結果が肯定的である場合、オリジンサーバーは 304 Not Modified 応答を送信します。