Citrix ADC

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

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

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

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

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

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

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

  • Varyヘッダーのサポートは制限されています。デフォルトでは、Vary ヘッダーを含む応答は、圧縮されていない限り、キャッシュ不可能とみなされます。圧縮された応答には、content-encoding:gzip、content-encoding:deflate、またはcontent-encoding:pack200-gzipが含まれ、Vary:Accept-encodingヘッダーが含まれている場合でもキャッシュ可能です。
  • 統合キャッシュは、ヘッダーcache-control:no-cacheおよびcache-control:privateの値を無視します。たとえば、cache-controlを含む応答: no-cache=”Set-Cookie” 応答にCache-Control:no-cacheが含まれているかのように扱われます。デフォルトでは、応答はキャッシュされません。
  • 画像(コンテンツタイプ = 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
<!--NeedCopy-->
  • リクエスト内の次のcache-controlヘッダーは、RFC準拠のキャッシュにオリジンサーバーからのキャッシュされた応答をリロードさせます。

Cache-control: max-age=0

Cache-control: no-cache

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

  • デフォルトでは、キャッシングモジュールは、応答ヘッダーの状態が別の場合を除いて、応答をキャッシュ可能と見なします。この動作をRFC2616に準拠させるには、すべてのコンテンツグループで -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

Citrix ADC GUIを使用して、コンテンツグループの応答Cookieの削除を構成する

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

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

統合キャッシュは、キャッシュ要求の結果として生じる応答にHTTPヘッダーを挿入できます。Citrix ADCアプライアンスは、キャッシュミスに起因する応答のヘッダーを変更しません。

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

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

年齢、経由、またはタグヘッダーを挿入します

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

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

コマンドプロンプトで入力します。

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

Citrix ADC GUIを使用して、Age、Via、または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ヘッダーを無視します

デフォルトでは、キャッシュモジュールは 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を使用して、リクエスト内のCache-ControlヘッダーとPragmaヘッダーを無視する

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

    Cache-ControlヘッダーとPragmaヘッダーを構成します

Cache-Controlヘッダーを無視するポリシーの例:

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

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

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

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

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

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

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

リクエストを受信するたびにオリジンサーバーをポーリングします

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

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

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

タグまたはLast-Modifiedヘッダーの形式のバリデーターを持つキャッシュされた応答の場合、応答の有効期限が切れると、自動的にPETとしてマークされ、キャッシュされます。

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

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

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

  • 条件付きリクエスト:クライアントは、それが持っている応答が最新のコピーであることを確認するために、条件付きリクエストを発行します。キャッシュされた PET 応答に対するユーザーエージェント要求は、常に条件付き要求に変換され、オリジンサーバーに送信されます。条件付きリクエストには、If-Modified-Since ヘッダーまたは If-None-Match ヘッダーにバリデータがあります。If-Modified-以来、ヘッダは、最終変更ヘッダからの時間が含まれています。If-None-Matchヘッダーには、応答のTagヘッダー値が含まれます。クライアントの応答のコピーが新しい場合、オリジンサーバーは 304 Not Modified と応答します。コピーが古い場合、条件付き応答では、応答全体を含む 200 OK が生成されます。
  • 非条件付きリクエスト:無条件リクエストは、応答全体を含む200OKのみを生成できます。
オリジン・サーバー・レスポンス 操作(アクション)
完全な回答を送信 オリジンサーバーは、応答をそのままクライアントに送信します。キャッシュされたレスポンスの有効期限が切れている場合は、リフレッシュされます。
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
<!--NeedCopy-->

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

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

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