製品ドキュメント
ADC
14.1 - Current Release 13.1 13.0 12.1
PDFを表示

Cookie、ヘッダー、およびポーリングを構成する

December 8, 2023
寄稿者: 
C

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

標準からのキャッシュ動作の相違について

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

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

組み込みのポリシーと [Default] コンテンツグループ属性により、これらの標準のほとんどに準拠していることが保証されます。

デフォルトの統合キャッシュの動作は、以下のように仕様とは違います。

  • ヴァリヘッダは限定的にサポートされています。デフォルトでは、ヴァリヘッダーを含むレスポンスは、圧縮されない限りキャッシュ不可とみなされます。圧縮された応答には、コンテンツエンコーディング:gzip、コンテンツエンコーディング:deflate、またはコンテンツエンコーディング:pack200-gzip が含まれており、Vary: Accept-encoding ヘッダーが含まれていてもキャッシュ可能です。
  • 統合キャッシュは、ヘッダーの cache-control (no-cache および cache-control: private) の値を無視します。たとえば、cache-control: no-cache= “set-cookie”を含むレスポンスは、レスポンスに Cache-Control: no-cache が含まれているかのように扱われます。デフォルトでは、レスポンスはキャッシュされません。
  • イメージレスポンスに set-cookie または set-cookie2 ヘッダーが含まれている場合や、イメージリクエストに Cookie ヘッダーが含まれている場合でも、イメージ（content-type = image/*）は常にキャッシュ可能と見なされます。統合キャッシュは、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-->
  • リクエスト内の次のキャッシュ制御ヘッダーは、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

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

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

レスポンスタイムに HTTP ヘッダを挿入する

統合キャッシュは、キャッシュリクエストから返されるレスポンスに HTTP ヘッダーを挿入できます。NetScalerアプライアンスは、キャッシュミスによる応答のヘッダーを変更しません。

次の表に、レスポンスに挿入できるヘッダーについて説明します。

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

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

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

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

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

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

NetScaler GUIを使用してAge、Via、またはEtagヘッダーを構成する

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

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

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

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

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

set cache contentgroup <name> -cacheControl <value>

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

  1. [ 最適化 ] > [ 統合キャッシュ ] > [ コンテンツグループ]に移動し、
    1. [ 有効期限方法 ] タブをクリックし、ヒューリスティックと既定の有効期限設定をクリアし、[コンテンツの有効期限が切れるまでの期間] テキストボックスで適切な値を設定します。
    2. [ その他 ] タブをクリックし、[Cache-Control] テキストボックスに挿入するヘッダーを入力します。または、[Configure] をクリックして、キャッシュされたレスポンスに Cache-Control ディレクティブを設定します。

リクエスト内のキャッシュコントロールとプラグマヘッダーを無視する

デフォルトでは、キャッシュモジュールは Cache-Control ヘッダーと Pragma ヘッダーを処理します。Cache-Control ヘッダー内の次のトークンは、RFC 2616 の説明に従って処理されます。

  • 最大年齢
  • 最大失効しました
  • キャッシュされた場合のみ有る
  • キャッシュなし

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

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

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

キャッシュコントロールとプラグマヘッダーを無視するための設定 ブラウザのリロード要求を無視する設定 結果
はい はいまたはいいえ Cache-Control: no-cache ディレクティブを含め、クライアントからの Cache-Control ヘッダーと Pragma ヘッダーは無視してください。
番号 はい Cache-Control: no-cache ヘッダーはキャッシュミスを生成しますが、すでにキャッシュにあるレスポンスは更新されません。
番号 番号 Cache-Control: no-cache ヘッダーを含むリクエストはキャッシュミスを引き起こし、保存されたレスポンスはリフレッシュされます。

コマンドラインインターフェイスを使用してリクエストの Cache-Control および Pragma ヘッダーを無視するには

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

set cache contentgroup <name> -ignoreReqCachingHdrs YES

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

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

set cache contentgroup <name> -ignoreReloadReq NO

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

GUI を使用してリクエストの Cache-Control ヘッダーと Pragma ヘッダーを無視する

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

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

次の例では、Content-type: image/* を含むレスポンスを、レスポンスの Cache-Control ヘッダーに関係なく、キャッシュするようにリクエスト時間オーバーライドポリシーを設定します。

image/* を含むすべてのレスポンスをキャッシュするようにリクエスト時間オーバーライドポリシーを設定するには

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

新しいキャッシュポリシーを設定し、そのポリシーを特定のコンテンツグループに向けます。詳しい情報については、「統合キャッシュのポリシーの設定」を参照してください。

「リクエストでの Cache-Control ヘッダーと Pragma ヘッダーを無視する」の説明に従って、ポリシーが使用するコンテンツグループが Cache-Control ヘッダーを無視するように設定されていることを確認します。

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

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

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

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

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

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

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

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

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

ポーリングは、次の 2 種類のリクエストに影響します。

  • 条件付きリクエスト:クライアントは、応答が最新のコピーであることを確認するために、条件付きリクエストを発行します。キャッシュされた PET 応答に対するユーザーエージェントリクエストは、常に条件付きリクエストに変換され、オリジンサーバーに送信されます。条件付きリクエストのIf-Modified-SinceヘッダーまたはIf-None-Matchヘッダーにバリデータがあります。If-Modified-SinceヘッダーにはLast-Modifiedヘッダーの時刻が含まれます。If-None-Match ヘッダーには、レスポンスの Tag ヘッダー値が含まれます。クライアントのレスポンスのコピーが新鮮な場合、オリジンサーバーは 304 Not Modified と応答します。コピーが古くなっている場合、条件付き応答では 200 OK が生成され、応答全体が格納されます。
  • 非条件付きリクエスト:非条件リクエストでは、レスポンス全体を含む 200 OK しか生成できません。
オリジンサーバーのレスポンス アクション
完全な回答を送信 オリジンサーバーはレスポンスをそのままクライアントに送信します。キャッシュされたレスポンスの有効期限が切れた場合、そのレスポンスはリフレッシュされます。
304 変更されていない 304 レスポンスのヘッダー値がキャッシュされたレスポンスとマージされ、キャッシュされたレスポンスがクライアントに提供されます。Date、Expires、Age、Cache-Control ヘッダー 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 Access (OWA) は、PET の恩恵を受ける動的に生成されたコンテンツの好例です。すべてのメールレスポンス (*.EML オブジェクト) には、PET ETag レスポンスとして保存できるバリデータがあります。

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

Cookie、ヘッダー、およびポーリングを構成する
December 8, 2023
寄稿者: 
C
December 8, 2023
寄稿者: 
C

この記事の概要

サイトに関するフィードバック | Your privacy choices footer linkプライバシーに関する選択肢 | プライバシーと法令 | Cookieの設定 | 同意設定 | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.