メインコンテンツまでスキップ

4. キャッシュからの応答の構築

リクエストを提示されたとき、キャッシュは、次のすべてに該当しない限り、格納された応答を再利用してはならない (MUST NOT)。

  • 提示された effective request URI ([RFC7230] のセクション 5.5) と、格納された応答のそれが一致すること、かつ

  • 格納された応答に関連付けられたリクエストメソッドが、提示されたリクエストにそれを使用することを認めていること、かつ

  • 格納された応答が指名する選択ヘッダーフィールド (存在する場合) が、提示されたものと一致すること (セクション 4.1 参照)、かつ

  • 提示されたリクエストに no-cache プラグマ (セクション 5.4) も no-cache キャッシュディレクティブ (セクション 5.2.1) も含まれていないこと (格納された応答が正常に検証されている場合 (セクション 4.3) を除く)、かつ

  • 格納された応答に no-cache キャッシュディレクティブ (セクション 5.2.2.2) が含まれていないこと (それが正常に検証されている場合 (セクション 4.3) を除く)、かつ

  • 格納された応答が次のいずれかであること:

    • フレッシュである (セクション 4.2 参照)、または

    • 古い状態で提供することが許可されている (セクション 4.2.4 参照)、または

    • 正常に検証されている (セクション 4.3 参照)。

上記の要件はいずれも、キャッシュ制御拡張によって上書きできることに注意してください。セクション 5.2.3 を参照してください。

検証を行わずに格納された応答を使ってリクエストを満たす場合、キャッシュは Age ヘッダーフィールド (セクション 5.1) を生成し、応答に存在するものを、格納された応答の current_age に等しい値で置き換えなければならない (MUST)。セクション 4.2.3 を参照してください。

キャッシュは、安全でないメソッド ([RFC7231] のセクション 4.2.1) を使用するリクエストをオリジンサーバーへライトスルーしなければならない (MUST)。すなわち、キャッシュは、そのリクエストを転送して対応する応答を受信する前に、そのようなリクエストへの応答を生成することは許されません。

また、安全でないリクエストはすでに格納されている応答を無効化する可能性があることに注意してください。セクション 4.4 を参照してください。

複数の適切な応答が格納されている場合、キャッシュは最も新しい応答 (Date ヘッダーフィールドによって決定されます) を使用しなければならない (MUST)。また、どの応答を使用すべきかの曖昧さを解消するために、"Cache-Control: max-age=0" または "Cache-Control: no-cache" を付けてリクエストを転送することもできます。

利用可能な時計を持たないキャッシュは、使用のたびに再検証することなく格納された応答を使用してはならない (MUST NOT)。

4.1. Vary による二次キーの計算​

キャッシュが、Vary ヘッダーフィールド ([RFC7231] のセクション 7.1.4) を持つ格納された応答で満たすことができるリクエストを受信した場合、その Vary ヘッダーフィールドが指名するすべての選択ヘッダーフィールドが、元のリクエスト (すなわち、格納された応答に関連付けられたもの) と提示されたリクエストの両方で一致しない限り、キャッシュはその応答を使用してはならない (MUST NOT)。

2 つのリクエストの選択ヘッダーフィールドは、次のいずれかを適用することによって、最初のリクエストのものが 2 番目のリクエストのものに変換できる場合に限り、一致するものと定義されます:

  • そのヘッダーフィールドの構文で許される位置で空白を追加または削除する

  • 同じフィールド名を持つ複数のヘッダーフィールドを結合する ([RFC7230] のセクション 3.2 参照)

  • そのヘッダーフィールドの仕様に従い、同一のセマンティクスを持つことが知られている方法で両方のヘッダーフィールドの値を正規化する (例えば、順序が重要でない場合にフィールド値を並べ替える、値が大文字と小文字を区別しないと定義されている場合に大文字と小文字を正規化する)

(行われる可能性のある正規化の後で) あるヘッダーフィールドがリクエストに存在しない場合、それがもう一方のリクエストにも存在しないときに限り、一致させることができます。

Vary ヘッダーフィールドの値が "*" である場合は常に一致に失敗します。

選択ヘッダーフィールドが一致する格納された応答は、選択された応答と呼ばれます。

複数の選択された応答が利用可能な場合 (Vary ヘッダーフィールドを持たない応答を含む可能性があります)、キャッシュは使用するものを 1 つ選ぶ必要があります。選択ヘッダーフィールドにそのための既知の機構がある場合 (例えば Accept や同様のリクエストヘッダーフィールドにおける qvalue)、その機構を使用して優先される応答を選択してもよい (MAY)。残りについては、セクション 4 に従い、最も新しい応答 (Date ヘッダーフィールドによって決定されます) が使用されます。

選択された応答が利用できない場合、キャッシュは提示されたリクエストを満たすことができません。通常、それは (条件付きである可能性のある; セクション 4.3 参照) リクエストとしてオリジンサーバーに転送されます。

4.2. 新鮮度​

フレッシュな応答とは、その年齢がまだ新鮮度ライフタイムを超えていない応答です。逆に、古い応答とは、超えてしまった応答です。

応答の新鮮度ライフタイムとは、それがオリジンサーバーによって生成されてから有効期限までの時間の長さです。明示的な有効期限とは、格納された応答がそれ以降はさらなる検証なしにキャッシュが使用できなくなる、とオリジンサーバーが意図する時点です。一方、ヒューリスティックな有効期限は、明示的な有効期限が利用できない場合にキャッシュが割り当てるものです。

応答の年齢とは、それがオリジンサーバーによって生成されるか、あるいはオリジンサーバーで正常に検証されてから経過した時間です。

応答がキャッシュ内で「フレッシュ」であるとき、それはオリジンサーバーに問い合わせることなく後続のリクエストを満たすために使用でき、それによって効率が向上します。

新鮮度を決定する主要な機構は、オリジンサーバーが Expires ヘッダーフィールド (セクション 5.3) または max-age 応答ディレクティブ (セクション 5.2.2.8) のいずれかを使って、将来の明示的な有効期限を提供することです。一般に、オリジンサーバーは、有効期限に達する前にその表現が意味的に重要な形で変化する可能性は低いと考えて、将来の明示的な有効期限を応答に割り当てます。

オリジンサーバーがキャッシュにすべてのリクエストを検証させたい場合、過去の明示的な有効期限を割り当てて、その応答がすでに古いことを示すことができます。準拠したキャッシュは通常、古いキャッシュ済み応答を後続のリクエストに再利用する前に検証します (セクション 4.2.4 参照)。

オリジンサーバーは常に明示的な有効期限を提供するわけではないため、キャッシュは特定の状況下でヒューリスティックを使って有効期限を決定することも許されています (セクション 4.2.2 参照)。

応答がフレッシュかどうかを判断する計算は次のとおりです:

response_is_fresh = (freshness_lifetime > current_age)

freshness_lifetime はセクション 4.2.1 で定義されています。current_age はセクション 4.2.3 で定義されています。

クライアントは、リクエスト内で max-age または min-fresh キャッシュディレクティブを送信して、対応する応答の新鮮度計算を厳しくしたり緩めたりできます (セクション 5.2.1)。

新鮮度を計算する際、日付解析における一般的な問題を避けるために、次のことに注意してください:

  • すべての日付形式は大文字と小文字を区別するものと規定されていますが、キャッシュの受信者は日付名、曜日名、およびタイムゾーン名を大文字と小文字を区別せずに照合すべきです (SHOULD)。

  • キャッシュの受信者の時間の内部実装の分解能が HTTP-date の値より低い場合、受信者は、解析した Expires の日付を、受信した値以下の最も近い時刻として内部的に表現しなければならない (MUST)。

  • キャッシュの受信者は、ローカルのタイムゾーンが年齢や有効期限の計算・比較に影響を与えることを許してはならない (MUST NOT)。

  • キャッシュの受信者は、GMT または UTC 以外のタイムゾーン略称を持つ日付を、有効期限の計算には無効と見なすべきです (SHOULD)。

新鮮度はキャッシュ操作にのみ適用されることに注意してください。ユーザーエージェントに表示の更新やリソースの再読み込みを強制するために使用することはできません。キャッシュと履歴機構の違いの説明については、セクション 6 を参照してください。

4.2.1. 新鮮度ライフタイムの計算​

キャッシュは、次の最初に一致したものを使用して、応答の新鮮度ライフタイム (freshness_lifetime と表記) を計算できます:

  • キャッシュが共有キャッシュであり、s-maxage 応答ディレクティブ (セクション 5.2.2.9) が存在する場合は、その値を使用する、または

  • max-age 応答ディレクティブ (セクション 5.2.2.8) が存在する場合は、その値を使用する、または

  • Expires 応答ヘッダーフィールド (セクション 5.3) が存在する場合は、その値から Date 応答ヘッダーフィールドの値を引いたものを使用する、または

  • それ以外の場合、応答に明示的な有効期限は存在しません。ヒューリスティックな新鮮度ライフタイムが適用できる可能性があります。セクション 4.2.2 を参照してください。

この計算は、すべての情報がオリジンサーバーから来るため、クロックスキューに対して脆弱ではないことに注意してください。

あるディレクティブに対して複数の値が存在する場合 (例えば、2 つの Expires ヘッダーフィールド、複数の Cache-Control: max-age ディレクティブ)、そのディレクティブの値は無効と見なされます。新鮮度情報が無効な応答は古いものと見なすことがキャッシュに推奨されます。

4.2.2. ヒューリスティックな新鮮度の計算​

オリジンサーバーは常に明示的な有効期限を提供するわけではないため、キャッシュは、明示的な時刻が指定されていない場合にヒューリスティックな有効期限を割り当ててもよい (MAY)。その際、他のヘッダーフィールドの値 (例えば Last-Modified の時刻) を使って妥当な有効期限を推定するアルゴリズムを用います。本仕様は特定のアルゴリズムを提供しませんが、その結果に対して最悪の場合の制約を課します。

格納された応答に明示的な有効期限が存在する場合、キャッシュはヒューリスティックを使って新鮮度を決定してはならない (MUST NOT)。セクション 3 の要件により、これは事実上、ヒューリスティックを、明示的な新鮮度を持たずステータスコードが既定でキャッシュ可能と定義されている応答 ([RFC7231] のセクション 6.1 参照) と、明示的な新鮮度を持たず明示的にキャッシュ可能とマークされた応答 (例えば "public" 応答ディレクティブによるもの) にのみ使用できることを意味します。

応答が Last-Modified ヘッダーフィールド ([RFC7232] のセクション 2.2) を持つ場合、キャッシュは、その時刻以降の間隔の何分の一かを超えないヒューリスティックな有効期限の値を使用することが推奨されます。この割合の典型的な設定は 10% 程度です。

ヒューリスティックを使って新鮮度ライフタイムを計算する場合、その current_age が 24 時間を超えており、そのような警告がまだ存在しないならば、キャッシュは 113 warn-code を持つ Warning ヘッダーフィールドを応答に生成すべきです (SHOULD) (セクション 5.5.4 参照)。

注: [RFC2616] のセクション 13.9 は、クエリコンポーネントを持つ URI (すなわち '?' を含むもの) についてヒューリスティックな新鮮度を計算することをキャッシュに禁じていました。実際には、これは広く実装されていません。したがって、キャッシュを排除したいオリジンサーバーは、明示的なディレクティブ (例えば Cache-Control: no-cache) を送信することが推奨されます。

4.2.3. 年齢の計算​

Age ヘッダーフィールドは、キャッシュから取得したときの応答メッセージの推定年齢を伝えるために使用されます。Age フィールドの値は、応答がオリジンサーバーによって生成または検証されてからの秒数に対するキャッシュの推定値です。本質的に、Age の値は、応答がオリジンサーバーからの経路上の各キャッシュに滞留した時間の合計に、ネットワーク経路上を転送されていた時間を加えたものです。

年齢の計算には次のデータが使用されます:

age_value

"age_value" という用語は、Age ヘッダーフィールド (セクション 5.1) の値を、算術演算に適した形で表します。利用できない場合は 0 です。

date_value

"date_value" という用語は、Date ヘッダーフィールドの値を、算術演算に適した形で表します。Date ヘッダーフィールドの定義、およびそれを持たない応答に関する要件については、[RFC7231] のセクション 7.1.1.2 を参照してください。

now

"now" という用語は、「計算を実行するホストにおける時計の現在の値」を意味します。ホストは、NTP ([RFC5905]) または同様のプロトコルを使用して、その時計を協定世界時に同期させるべきです。

request_time

格納された応答をもたらしたリクエストが行われた時点での、ホストにおける時計の現在の値。

response_time

応答が受信された時点での、ホストにおける時計の現在の値。

応答の年齢は、完全に独立した 2 つの方法で計算できます:

  1. "apparent_age": ローカルクロックがオリジンサーバーのクロックと十分に同期している場合、response_time から date_value を引いたもの。結果が負の場合、結果は 0 に置き換えられます。

  2. "corrected_age_value": 応答経路上のすべてのキャッシュが HTTP/1.1 を実装している場合。キャッシュは、この値を応答を受信した時刻ではなく、リクエストが開始された時刻を基準として解釈しなければならない (MUST)。

apparent_age = max(0, response_time - date_value);

response_delay = response_time - request_time;
corrected_age_value = age_value + response_delay;

これらは次のように結合されます:

corrected_initial_age = max(apparent_age, corrected_age_value);

ただし、キャッシュが Age ヘッダーフィールドの値に確信を持っている場合 (例えば、Via ヘッダーフィールドに HTTP/1.0 のホップがないため) は別で、その場合は corrected_age_value を corrected_initial_age として使用してもよい (MAY)。

格納された応答の current_age は、その格納された応答が最後にオリジンサーバーによって検証されてから経過した時間 (秒) を corrected_initial_age に加えることで計算できます。

resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;

4.2.4. 古い応答の提供​

「古い」応答とは、明示的な有効期限情報を持つか、ヒューリスティックな有効期限を計算することが認められているものの、セクション 4.2 の計算によればフレッシュではない応答です。

明確なプロトコル内ディレクティブによって禁止されている場合 (例えば、"no-store" または "no-cache" キャッシュディレクティブ、"must-revalidate" キャッシュ応答ディレクティブ、あるいは該当する "s-maxage" または "proxy-revalidate" キャッシュ応答ディレクティブによる場合; セクション 5.2.2 参照)、キャッシュは古い応答を生成してはならない (MUST NOT)。

キャッシュは、切断されている場合 (すなわち、オリジンサーバーに連絡できないか、転送経路を他の方法で見つけられない場合)、またはそうすることが明示的に許可されている場合 (例えば max-stale リクエストディレクティブによる場合; セクション 5.2.1 参照) を除き、古い応答を送信してはならない (MUST NOT)。

キャッシュは、古い応答に 110 warn-code を持つ Warning ヘッダーフィールドを生成すべきです (SHOULD) (セクション 5.5.1 参照)。同様に、キャッシュが切断されている場合、キャッシュは古い応答に 112 warn-code を生成すべきです (SHOULD) (セクション 5.5.3 参照)。

キャッシュは、Age ヘッダーフィールドを持たない応答を転送する際、その応答がすでに古い場合でも、新しい Warning ヘッダーフィールドを生成すべきではありません (SHOULD NOT)。キャッシュは、転送中に単に古くなっただけの応答を検証する必要はありません。

4.3. 検証​

キャッシュが、要求された URI に対して 1 つ以上の格納された応答を持っているにもかかわらず、そのいずれも提供できない場合 (例えば、それらがフレッシュでないため、あるいは選択できないため; セクション 4.1 参照)、キャッシュは転送するリクエストで条件付きリクエスト機構 [RFC7232] を使用して、次のインバウンドサーバーに、使用する有効な格納済み応答を選択する機会 (その過程で格納されたメタデータを更新します)、または格納された応答を新しい応答で置き換える機会を与えることができます。このプロセスは、格納された応答の「検証」または「再検証」と呼ばれます。

4.3.1. 検証リクエストの送信​

キャッシュ検証のために条件付きリクエストを送信するとき、キャッシュは、自身の格納された応答からのバリデータメタデータを含む 1 つ以上の事前条件ヘッダーフィールドを送信します。受信者はこれを比較して、格納された応答がリソースの現在の表現と等価かどうかを判断します。

そのようなバリデータの 1 つは、Last-Modified ヘッダーフィールド ([RFC7232] のセクション 2.2) に与えられるタイムスタンプであり、応答の検証のために If-Modified-Since ヘッダーフィールドで、あるいは表現の選択のために If-Unmodified-Since または If-Range ヘッダーフィールドで使用できます (すなわち、クライアントはそのタイムスタンプを持つ以前に取得した表現を特定的に指しています)。

もう 1 つのバリデータは、ETag ヘッダーフィールド ([RFC7232] のセクション 2.3) に与えられるエンティティタグです。1 つ以上の格納された応答を示す 1 つ以上のエンティティタグは、応答の検証のために If-None-Match ヘッダーフィールドで、あるいは表現の選択のために If-Match または If-Range ヘッダーフィールドで使用できます (すなわち、クライアントは列挙されたエンティティタグを持つ 1 つ以上の以前に取得した表現を特定的に指しています)。

4.3.2. 受信した検証リクエストの処理​

リクエストチェーン内の各クライアントは独自のキャッシュを持つ可能性があるため、中間要素のキャッシュが他の (アウトバウンド) キャッシュから条件付きリクエストを受信することはよくあります。同様に、一部のユーザーエージェントは、データ転送を最近変更された表現に限定したり、部分的に取得した表現の転送を完了したりするために、条件付きリクエストを利用します。

キャッシュが、格納された 200 (OK) または 206 (Partial Content) 応答のいずれかを再利用することで満たせるリクエストを受信した場合、キャッシュは、そのリクエストで受信した該当する条件付きヘッダーフィールドの事前条件を、選択された応答に含まれる対応するバリデータに対して評価すべきです (SHOULD)。キャッシュは、オリジンサーバーにのみ適用される条件付きヘッダーフィールド、キャッシュされた応答では満たせないセマンティクスを持つリクエストに見られるもの、または格納された応答を持たないターゲットリソースに適用されるものを評価してはならない (MUST NOT)。そのような事前条件は、おそらく他の (インバウンド) サーバー向けのものです。

キャッシュによる条件付きリクエストの適切な評価は、[RFC7232] のセクション 6 で定義されているように、受信した事前条件ヘッダーフィールドとその優先順位に依存します。If-Match および If-Unmodified-Since 条件付きヘッダーフィールドは、キャッシュには適用されません。

If-None-Match ヘッダーフィールド ([RFC7232] のセクション 3.2) を含むリクエストは、クライアントが、自身の 1 つ以上の格納された応答を、キャッシュが選択した格納済み応答と比較して検証したいことを示します。フィールド値が "*" である場合、またはフィールド値がエンティティタグのリストでありその少なくとも 1 つが選択された格納済み応答のエンティティタグと一致する場合、キャッシュの受信者は、その格納済み応答を送信する代わりに、(選択された格納済み応答のメタデータを使用して) 304 (Not Modified) 応答を生成すべきです (SHOULD)。

キャッシュが、If-None-Match のエンティティタグリストを含むリクエストに対して自身の格納済み応答を再検証することを決めた場合、キャッシュは、受信したリストを自身の格納済み応答集合 (フレッシュまたは古い) からのエンティティタグのリストと結合し、2 つのリストの和集合を、転送するリクエストにおける置き換えの If-None-Match ヘッダーフィールド値として送信してもよい (MAY)。格納された応答が部分コンテンツのみを含む場合、キャッシュは、その部分的な格納済み応答によって完全に満たされる範囲をリクエストが求めているのでない限り、そのエンティティタグを和集合に含めてはならない (MUST NOT)。転送したリクエストへの応答が 304 (Not Modified) であり、クライアントのリストにないエンティティタグを持つ ETag ヘッダーフィールド値を持っている場合、キャッシュは、304 応答のメタデータによって更新された対応する格納済み応答を再利用して、クライアント向けの 200 (OK) 応答を生成しなければならない (MUST) (セクション 4.3.4 参照)。

If-None-Match ヘッダーフィールドが存在しない場合、If-Modified-Since ヘッダーフィールド ([RFC7232] のセクション 3.3) を含むリクエストは、クライアントが、自身の 1 つ以上の格納された応答を変更日によって検証したいことを示します。次のいずれかの場合に該当するならば、キャッシュの受信者は (選択された格納済み応答のメタデータを使用して) 304 (Not Modified) 応答を生成すべきです (SHOULD): 1) 選択された格納済み応答の Last-Modified フィールド値が条件のタイムスタンプ以前である、2) 選択された格納済み応答に Last-Modified フィールドが存在しないが、条件のタイムスタンプ以前の Date フィールド値を持つ、または 3) 選択された格納済み応答に Last-Modified も Date も存在しないが、キャッシュがそれを条件のタイムスタンプ以前に受信したものとして記録している。

[RFC7233] で定義されている範囲リクエストへの部分応答を実装するキャッシュは、受信した If-Range ヘッダーフィールド ([RFC7233] のセクション 3.2) を、選択された格納済み応答に対して評価する必要もあります。

4.3.3. 検証応答の処理​

条件付きリクエストへの応答のキャッシュによる処理は、そのステータスコードに依存します:

  • 304 (Not Modified) 応答ステータスコードは、格納された応答を更新して再利用できることを示します。セクション 4.3.4 を参照してください。

  • 完全な応答 (すなわちペイロード本体を持つもの) は、条件付きリクエストで指名された格納済み応答のいずれも適切でないことを示します。代わりに、キャッシュはその完全な応答を使用してリクエストを満たさなければならず (MUST)、格納された応答を置き換えてもよい (MAY)。

  • ただし、キャッシュが応答を検証しようとしているときに 5xx (Server Error) 応答を受信した場合、その応答を要求元のクライアントに転送するか、サーバーが応答に失敗したかのように振る舞うことができます。後者の場合、キャッシュは以前に格納された応答を送信してもよい (MAY) (セクション 4.2.4 参照)。

4.3.4. 検証時の格納済み応答の更新​

キャッシュが 304 (Not Modified) 応答を受信し、同じキャッシュキーに対してすでに 1 つ以上の格納された 200 (OK) 応答を持っている場合、キャッシュは、この新しい応答によっていずれの格納済み応答が更新されるかを特定し、その後、304 応答で提供された新しい情報でその格納済み応答を更新する必要があります。

更新する格納済み応答は、次の最初に一致したもの (存在する場合) を使用して特定されます:

  • 新しい応答が強バリデータ ([RFC7232] のセクション 2.1 参照) を含む場合、その強バリデータが更新対象の選択された表現を特定します。同じ強バリデータを持つ格納済み応答がすべて選択されます。格納済み応答のいずれも同じ強バリデータを含まない場合、キャッシュは新しい応答をいかなる格納済み応答の更新にも使用してはならない (MUST NOT)。

  • 新しい応答が弱バリデータを含み、そのバリデータがキャッシュの格納済み応答の 1 つに対応する場合、それらの一致する格納済み応答のうち最も新しいものが更新対象として選択されます。

  • 新しい応答がいかなる形式のバリデータも含まず (例えば、クライアントが Last-Modified 応答ヘッダーフィールド以外のソースから If-Modified-Since リクエストを生成する場合)、格納済み応答が 1 つだけで、その格納済み応答もバリデータを欠いている場合、その格納済み応答が更新対象として選択されます。

格納済み応答が更新対象として選択された場合、キャッシュは次を行わなければならない (MUST):

  • 格納済み応答内の warn-code 1xx の Warning ヘッダーフィールドをすべて削除する (セクション 5.5 参照)。

  • 格納済み応答内の warn-code 2xx の Warning ヘッダーフィールドをすべて保持する。そして、

  • 304 (Not Modified) 応答で提供されたその他のヘッダーフィールドを使用して、格納済み応答内の対応するヘッダーフィールドのすべてのインスタンスを置き換える。

4.3.5. HEAD による応答の更新​

HEAD メソッドへの応答は、GET で行われた同等のリクエストの応答と同一ですが、本体を欠いています。HEAD 応答のこの性質は、(格納済み応答にバリデータが存在しないために) より効率的な条件付き GET リクエスト機構が利用できない場合、または表現本体が変更されていてもその転送を望まない場合に、キャッシュされた GET 応答を無効化または更新するために使用できます。

キャッシュが、与えられたリクエストターゲットに対してインバウンド HEAD リクエストを行い、200 (OK) 応答を受信した場合、キャッシュは、そのリクエストに対して選択され得た自身の格納済み GET 応答のそれぞれを更新または無効化すべきです (SHOULD) (セクション 4.1 参照)。

選択され得た格納済み応答のそれぞれについて、格納済み応答と HEAD 応答が、受信したいずれかのバリデータフィールド (ETag および Last-Modified) で一致する値を持ち、かつ HEAD 応答が Content-Length ヘッダーフィールドを持つ場合はその Content-Length の値が格納済み応答のものと一致するならば、キャッシュは以下に述べるようにその格納済み応答を更新すべきです (SHOULD)。そうでない場合、キャッシュはその格納済み応答を古いものと見なすべきです (SHOULD)。

キャッシュが HEAD 応答で提供されたメタデータで格納済み応答を更新する場合、キャッシュは次を行わなければならない (MUST):

  • 格納済み応答内の warn-code 1xx の Warning ヘッダーフィールドをすべて削除する (セクション 5.5 参照)。

  • 格納済み応答内の warn-code 2xx の Warning ヘッダーフィールドをすべて保持する。そして、

  • HEAD 応答で提供されたその他のヘッダーフィールドを使用して、格納済み応答内の対応するヘッダーフィールドのすべてのインスタンスを置き換え、新しいヘッダーフィールドを格納済み応答のヘッダーセクションに追加する。ただし Cache-Control ヘッダーフィールドによって別途制限されている場合を除く。

4.4. 無効化​

PUT、POST、DELETE などの安全でないリクエストメソッド ([RFC7231] のセクション 4.2.1) はオリジンサーバーの状態を変化させる可能性があるため、介在するキャッシュはそれらを利用して自身の内容を最新に保つことができます。

安全でないリクエストメソッドへの応答として非エラーステータスコードを受信した場合、キャッシュは、effective Request URI ([RFC7230] のセクション 5.5) ならびに Location および Content-Location 応答ヘッダーフィールド内の URI (存在する場合) を無効化しなければならない (MUST)。

ただし、Location または Content-Location 応答ヘッダーフィールドの URI のホスト部分が、effective request URI ([RFC7230] のセクション 5.5) のホスト部分と異なる場合、キャッシュはその URI を無効化してはならない (MUST NOT)。これはサービス妨害攻撃の防止に役立ちます。

キャッシュは、安全性が不明なメソッドのリクエストに対して非エラー応答を受信したとき、effective request URI ([RFC7230] のセクション 5.5) を無効化しなければならない (MUST)。

ここで、「非エラー応答」とは、2xx (Successful) または 3xx (Redirection) ステータスコードを持つ応答です。「無効化する」とは、キャッシュが effective request URI に関連するすべての格納済み応答を削除するか、それらを「無効」としてマークし、後続のリクエストに応答して送信する前に必須の検証を必要とすることを意味します。

これは、すべての適切な応答が無効化されることを保証するものではないことに注意してください。例えば、状態を変化させるリクエストは、それが通過するキャッシュ内の応答を無効化するかもしれませんが、関連する応答が、それが通過しなかった他のキャッシュに依然として格納されている可能性があります。