Cookie、ヘッダー、およびポーリングを構成する
このトピックでは、Cookie、HTTP ヘッダー、およびオリジンサーバーのポーリングを管理するキャッシュを構成する方法について説明します。これには、キャッシュが文書化された標準から外れるようなデフォルトの動作の変更、キャッシュ可能なコンテンツがキャッシュに保存されなくなる可能性がある HTTP ヘッダーのオーバーライド、更新されたコンテンツについてオリジンに常にポーリングするようにキャッシュを設定することが含まれます。
Related information
標準からのキャッシュ動作の相違について
デフォルトでは、統合キャッシュは次の RFC 標準に準拠しています。
-
RFC 2616「HTTP HTTP/1.1」
-
RFC 2617「HTTP 認証:基本認証とダイジェストアクセス認証」で説明されているキャッシュ動作
-
RFC 2965「HTTP 状態管理メカニズム」で説明されているキャッシュ動作
デフォルトの統合キャッシュの動作は、以下のように仕様とは違います。
-
ヴァリヘッダは限定的にサポートされています。デフォルトでは、ヴァリヘッダーを含むレスポンスは、圧縮されない限りキャッシュ不可とみなされます。圧縮された応答には、コンテンツエンコーディング: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
-
リクエスト内の次のキャッシュ制御ヘッダーは、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の削除を構成する
レスポンスタイムに 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ヘッダーを構成する
キャッシュコントロールヘッダを挿入する
統合キャッシュが、オリジンサーバーが挿入した Cache-Control ヘッダーを置き換える場合、Expires ヘッダーも置き換えられます。新しい Expires ヘッダーには、過去の有効期限が含まれています。これにより、HTTP/1.0 クライアントと (Cache-Control ヘッダーを認識しない) キャッシュがコンテンツをキャッシュしないようにします。
NetScalerコマンドインターフェイスを使用してキャッシュ制御ヘッダーを挿入する
コマンドプロンプトで入力します：
set cache contentgroup <name> -cacheControl <value>
NetScaler GUIを使用してキャッシュ制御ヘッダーを挿入する
リクエスト内のキャッシュコントロールとプラグマヘッダーを無視する
デフォルトでは、キャッシュモジュールは 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 ヘッダーを無視する
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 を使用してポーリングする
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 Access (OWA) は、PET の恩恵を受ける動的に生成されたコンテンツの好例です。すべてのメールレスポンス (*.EML オブジェクト) には、PET
ETag レスポンスとして保存できるバリデータがあります。
メールレスポンスのリクエストはすべて、レスポンスがキャッシュされていても、オリジンサーバーに送信されます。オリジンサーバーは、リクエスタが認証され、承認されているかどうかを判断します。また、オリジンサーバーに応答が存在するかどうかも検証します。すべての結果が肯定的である場合、オリジンサーバーは 304 Not Modified レスポンスを送信します。