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

4. Constructing Responses from Caches (キャッシュからの応答の構築)

リクエストを受け取った場合、以下のすべての条件が満たされない限り、キャッシュは保存された応答を再利用してはなりません (MUST NOT):

  • 提示されたターゲットURI ([HTTP]のセクション7.1を参照) が保存された応答のターゲットURIと一致している、および

  • 保存された応答に関連付けられたリクエストメソッドが、提示されたリクエストに使用できる、および

  • 保存された応答によって指定されたリクエストヘッダーフィールド (存在する場合) が提示されたリクエストのものと一致している (セクション4.1を参照)、および

  • 保存された応答にno-cacheディレクティブ (セクション5.2.2.4) が含まれていない、または正常に検証されている (セクション4.3)、および

  • 保存された応答が以下のいずれかである:

    • 新鮮である (セクション4.2を参照)、または

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

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

キャッシュ拡張は上記の要件のいずれかをオーバーライドできることに注意してください。セクション5.2.3を参照してください。

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

キャッシュは、安全でないメソッド ([HTTP]のセクション9.2.1を参照) を持つリクエストをオリジンサーバーに直接書き込まなければなりません (MUST)。つまり、キャッシュは、リクエストを転送して対応する応答を受信する前に、そのようなリクエストへの応答を生成することは許可されていません。

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

キャッシュは、問題のリクエストに対して応答の再利用が許可されている場合、保存された応答または保存可能な応答を使用して複数のリクエストを満たしてもかまいません (MAY)。これにより、キャッシュは「リクエストを折りたたむ (Collapse Requests)」ことができます。つまり、キャッシュミス時に複数の着信リクエストを単一の転送リクエストに結合し、オリジンサーバーとネットワークの負荷を削減できます。ただし、キャッシュが返された応答を折りたたまれたリクエストの一部または全部に使用できない場合、それらを満たすためにそれらのリクエストを転送する必要があり、追加の遅延が発生する可能性があることに注意してください。

複数の適切な応答が保存されている場合、キャッシュは最新の応答 (Dateヘッダーフィールドによって決定される) を使用しなければなりません (MUST)。また、「Cache-Control: max-age=0」または「Cache-Control: no-cache」を使用してリクエストを転送し、使用する応答を明確にすることもできます。

時計を持たない ([HTTP]のセクション5.6.7を参照) キャッシュは、使用するたびに保存された応答を再検証しなければなりません (MUST)。

4.1 Calculating Cache Keys with the Vary Header Field (Varyヘッダーフィールドを使用したキャッシュキーの計算)​

キャッシュが保存された応答で満たすことができるリクエストを受信し、その保存された応答にVaryヘッダーフィールド ([HTTP]のセクション12.5.5を参照) が含まれている場合、Varyフィールド値によって指定されたすべてのリクエストヘッダーフィールドが元のリクエスト (つまり、キャッシュされた応答が保存される原因となったリクエスト) と提示されたリクエストの両方で一致しない限り、キャッシュは再検証なしでその保存された応答を使用してはなりません (MUST NOT)。

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

  • ヘッダーフィールドの構文で許可されている場合の空白の追加または削除

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

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

ヘッダーフィールドがリクエストに存在しない場合、それは他のリクエストにも存在しない場合にのみ一致できます。

メンバー「*」を含むVaryヘッダーフィールド値を持つ保存された応答は、常に一致に失敗します。

複数の保存された応答が一致する場合、キャッシュは使用するものを選択する必要があります。指定されたリクエストヘッダーフィールドに既知の優先順位付けメカニズム (例えば、Acceptおよび類似のリクエストヘッダーフィールドのqvalues) がある場合、そのメカニズムを使用して優先応答を選択してもかまいません (MAY)。そのようなメカニズムが存在しないか、同等に優先される応答になる場合、セクション4に従って、最新の応答 (Dateヘッダーフィールドによって決定される) が選択されます。

一部のリソースは、デフォルトの応答 (つまり、リクエストが優先順位を表明しない場合に送信される応答) からVaryヘッダーフィールドを誤って省略し、より好ましい応答が利用可能な場合でも、そのリソースへの後続のリクエストに対して選択されるという効果があります。キャッシュがターゲットURIに対して複数の保存された応答を持ち、1つ以上がVaryヘッダーフィールドを省略している場合、キャッシュは有効なVaryフィールド値を持つ最新の (セクション4.2.3を参照) 保存された応答を選択すべきです (SHOULD)。

一致する保存された応答がない場合、キャッシュは提示されたリクエストを満たすことができません。通常、リクエストはオリジンサーバーに転送され、キャッシュが既に保存している応答を記述する前提条件が追加される可能性があります (セクション4.3)。

4.2 Freshness (新鮮度)​

「新鮮 (Fresh)」な応答とは、その年齢がまだ新鮮度ライフタイムを超えていない応答です。逆に、「古い (Stale)」応答とは、それを超えた応答です。

応答の「新鮮度ライフタイム (Freshness Lifetime)」は、オリジンサーバーによる生成から有効期限までの時間の長さです。「明示的有効期限 (Explicit Expiration Time)」は、オリジンサーバーがさらなる検証なしにキャッシュが保存された応答を使用しなくなることを意図する時刻であり、「ヒューリスティック有効期限 (Heuristic Expiration Time)」は、明示的な有効期限が利用できない場合にキャッシュによって割り当てられる時刻です。

応答の「年齢 (Age)」は、オリジンサーバーで生成または正常に検証されてから経過した時間です。

応答が新鮮な場合、オリジンサーバーに連絡することなく後続のリクエストを満たすために使用でき、効率が向上します。

新鮮度を決定する主要なメカニズムは、オリジンサーバーがExpiresヘッダーフィールド (セクション5.3) またはmax-age応答ディレクティブ (セクション5.2.2.1) のいずれかを使用して、将来の明示的な有効期限を提供することです。通常、オリジンサーバーは、その有効期限の前に表現が意味的に重要な方法で変更される可能性が低いと信じて、応答に将来の明示的な有効期限を割り当てます。

オリジンサーバーがキャッシュにすべてのリクエストを検証させたい場合、過去の明示的な有効期限を割り当てて、応答が既に古いことを示すことができます。準拠するキャッシュは通常、再利用する前に古いキャッシュ応答を検証します (セクション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」以外のタイムゾーン略語を持つ日付を、有効期限の計算に無効であると見なすべきです (SHOULD)。

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

4.2.1 Calculating Freshness Lifetime (新鮮度ライフタイムの計算)​

キャッシュは、以下のルールを評価し、最初に一致するものを使用することによって、応答の新鮮度ライフタイム (freshness_lifetimeと表記) を計算できます:

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

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

  • Expires応答ヘッダーフィールド (セクション5.3) が存在する場合、その値からDate応答ヘッダーフィールドの値を引いた値を使用する (存在しない場合は、[HTTP]のセクション6.6.1に従って、メッセージが受信された時刻を使用)、または

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

この計算は、オリジンサーバーの時計からの情報をできるだけ使用することにより、時計のずれを減らすことを意図していることに注意してください。

特定のディレクティブが複数回出現する場合 (例えば、2つのExpiresヘッダーフィールド行または複数のCache-Control: max-ageディレクティブ)、最初の出現を使用するか、応答を古いと見なす必要があります。ディレクティブが競合する場合 (例えば、max-ageとno-cacheの両方が存在する場合)、最も制限的なディレクティブを尊重する必要があります。キャッシュは、無効な新鮮度情報 (例えば、非整数コンテンツを持つmax-ageディレクティブ) を持つ応答を古いと見なすことが推奨されます。

4.2.2 Calculating Heuristic Freshness (ヒューリスティック新鮮度の計算)​

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

保存された応答に明示的な有効期限が存在する場合、キャッシュはヒューリスティックを使用して新鮮度を決定してはなりません (MUST NOT)。セクション3の要件により、ヒューリスティックは、明示的な新鮮度を持たず、そのステータスコードによってヒューリスティックにキャッシュ可能 ([HTTP]のセクション15.1などを参照) であることが許可されているか、明示的にキャッシュ可能としてマークされている (例えば、public応答ディレクティブを使用) 応答にのみ使用できます。

以前の仕様では、ヒューリスティックにキャッシュ可能な応答ステータスコードは「デフォルトでキャッシュ可能 (Cacheable by Default)」として知られていたことに注意してください。

応答にLast-Modifiedヘッダーフィールド ([HTTP]のセクション8.8.2を参照) がある場合、キャッシュはその時刻以降の間隔の一部を超えないヒューリスティック有効期限値を使用することが推奨されます。この割合の典型的な設定は10%である可能性があります。

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

4.2.3 Calculating Age (年齢の計算)​

Ageヘッダーフィールドは、キャッシュから取得された場合の応答メッセージの推定年齢を伝えるために使用されます。Ageフィールド値は、応答がオリジンサーバーで生成または検証されてからの秒数のキャッシュの推定値です。したがって、Age値は、応答がオリジンサーバーから到着するまでのパス上の各キャッシュに駐在した時間の合計に、ネットワークパス上で送信に費やされた時間を加えたものです。

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

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

date_value 「date_value」という用語は、算術演算に適した形式のDateヘッダーフィールドの値を示します。Dateヘッダーフィールドの定義とそれがない応答の要件については、[HTTP]のセクション6.6.1を参照してください。

now 「now」という用語は、この実装の時計 ([HTTP]のセクション5.6.7を参照) の現在の値を示します。

request_time 保存された応答をもたらしたリクエストの時刻の時計の値。

response_time 応答が受信された時刻の時計の値。

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

  1. 「apparent_age」: 実装の時計がオリジンサーバーの時計と合理的によく同期されている場合、response_timeからdate_valueを引いた値。結果が負の場合、結果はゼロに置き換えられます。

  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_age_valueは、corrected_initial_ageとして使用してもかまいません (MAY)。Ageを適切に挿入しない可能性のある非常に古いキャッシュ実装が存在する可能性がある場合、corrected_initial_ageはより保守的に次のように計算できます:

corrected_initial_age = max(apparent_age, corrected_age_value);

保存された応答のcurrent_ageは、corrected_initial_ageに、保存された応答が最後にオリジンサーバーによって検証されてからの時間 (秒単位) を追加することで計算できます。

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

4.2.4 Serving Stale Responses (古い応答の提供)​

「古い (Stale)」応答とは、明示的な有効期限情報を持つか、ヒューリスティック有効期限の計算を許可し、セクション4.2の計算に従って新鮮でない応答です。

明示的なプロトコル内ディレクティブ (例えば、no-cache応答ディレクティブ、must-revalidate応答ディレクティブ、または適用可能なs-maxageまたはproxy-revalidate応答ディレクティブ。セクション5.2.2を参照) によって禁止されている場合、キャッシュは古い応答を生成してはなりません (MUST NOT)。

キャッシュが切断されているか、クライアントまたはオリジンサーバーによって明示的に許可されている (例えば、セクション5.2.1のmax-staleリクエストディレクティブ、[RFC5861]で定義された拡張ディレクティブ、または帯域外契約に従った設定による) 場合を除き、キャッシュは古い応答を生成してはなりません (MUST NOT)。

4.3 Validation (検証)​

キャッシュがリクエストされたURIに対して1つ以上の保存された応答を持っているが、そのいずれも提供できない場合 (例えば、それらが新鮮でないか、適切なものを選択できないため。セクション4.1を参照)、転送されたリクエストで条件付きリクエストメカニズム ([HTTP]のセクション13を参照) を使用して、次のインバウンドサーバーに、使用する有効な保存された応答を選択する機会を与え、プロセス中に保存されたメタデータを更新するか、保存された応答を新しい応答で置き換えることができます。このプロセスは、保存された応答を「検証する (Validating)」または「再検証する (Revalidating)」として知られています。

4.3.1 Sending a Validation Request (検証リクエストの送信)​

検証のための条件付きリクエストを生成する際、キャッシュは、満たそうとしているリクエストから開始するか、または独立してリクエストを開始している場合は、メソッド、ターゲットURI、およびVaryヘッダーフィールド (セクション4.1) によって識別されたリクエストヘッダーフィールドをコピーすることによって、保存された応答を使用してリクエストを合成します。

次に、1つ以上の前提条件ヘッダーフィールドを使用してそのリクエストを更新します。これらには、同じURIの保存された応答から取得されたバリデータメタデータが含まれます。通常、これには同じキャッシュキーを持つ保存された応答のみが含まれますが、キャッシュは提示されたリクエストヘッダーフィールドを使用して選択できない応答を検証することが許可されています (セクション4.1を参照)。

次に、受信者は前提条件ヘッダーフィールドを比較して、保存された応答がリソースの現在の表現と等価かどうかを判断します。

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

別のバリデータは、ETagフィールド ([HTTP]のセクション8.8.3を参照) で与えられるエンティティタグです。1つ以上のエンティティタグ (1つ以上の保存された応答を示す) は、応答検証のためにIf-None-Matchヘッダーフィールドで、または表現選択のためにIf-MatchまたはIf-Rangeヘッダーフィールドで使用できます (つまり、クライアントはリストされたエンティティタグを持つ1つ以上の以前に取得した表現を具体的に参照しています)。

検証のための条件付きリクエストを生成する際、キャッシュは:

  • 検証されている保存された応答にエンティティタグが提供されている場合、関連するエンティティタグ (If-Match、If-None-Match、またはIf-Rangeを使用) を送信しなければなりません (MUST)。

  • リクエストがサブ範囲のものではなく、単一の保存された応答が検証されており、その応答にLast-Modified値が含まれている場合、Last-Modified値 (If-Modified-Sinceを使用) を送信すべきです (SHOULD)。

  • リクエストがサブ範囲のものであり、単一の保存された応答が検証されており、その応答にLast-Modified値のみ (エンティティタグの代わりに) が含まれている場合、Last-Modified値 (If-Unmodified-SinceまたはIf-Rangeを使用) を送信してもかまいません (MAY)。

ほとんどの場合、エンティティタグが明らかに優れている場合でも、エンティティタグ前提条件を理解しない古い中間装置が適切に応答できるように、キャッシュ検証リクエストでは両方のバリデータが生成されます。

4.3.2 Handling a Received Validation Request (受信した検証リクエストの処理)​

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

キャッシュが保存された200 (OK) または206 (Partial Content) 応答を再利用することで満たすことができるリクエスト (セクション4による) を受信した場合、キャッシュは、保存された応答に含まれる対応するバリデータに関して、そのリクエストで受信した適用可能な条件ヘッダーフィールド前提条件を評価すべきです (SHOULD)。

キャッシュは、オリジンサーバーにのみ適用される条件ヘッダーフィールド、キャッシュされた応答でセマンティクスを満たすことができないリクエストに出現する条件ヘッダーフィールド、または保存された応答がないターゲットリソースのリクエストに出現する条件ヘッダーフィールドを評価してはなりません (MUST NOT)。これらの前提条件は、他の (インバウンド) サーバーを対象としている可能性があります。

キャッシュによる条件付きリクエストの適切な評価は、受信した前提条件ヘッダーフィールドとその優先順位に依存します。要約すると、If-MatchおよびIf-Unmodified-Since条件ヘッダーフィールドはキャッシュに適用されず、If-None-MatchはIf-Modified-Sinceよりも優先されます。前提条件の優先順位の完全な仕様については、[HTTP]のセクション13.2.2を参照してください。

If-None-Matchヘッダーフィールド ([HTTP]のセクション13.1.2を参照) を含むリクエストは、クライアントがキャッシュによって選択された保存された応答 (セクション4による) と比較して、自身の1つ以上の保存された応答を検証したいことを示しています。

If-None-Matchヘッダーフィールドが存在しない場合、If-Modified-Sinceヘッダーフィールド ([HTTP]のセクション13.1.3を参照) を含むリクエストは、クライアントが変更日によって自身の1つ以上の保存された応答を検証したいことを示しています。

リクエストにIf-Modified-Sinceヘッダーフィールドが含まれ、保存された応答にLast-Modifiedヘッダーフィールドが存在しない場合、キャッシュは保存された応答のDateフィールド値 (またはDateフィールドが存在しない場合は保存された応答が受信された時刻) を使用して条件を評価すべきです (SHOULD)。

範囲リクエストに対する部分応答を実装するキャッシュ ([HTTP]のセクション14.2で定義) は、キャッシュが選択した応答に関して、受信したIf-Rangeヘッダーフィールド ([HTTP]のセクション13.1.5を参照) も評価する必要があります。

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

4.3.3 Handling a Validation Response (検証応答の処理)​

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

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

  • 完全な応答 (つまり、コンテンツを含む応答) は、条件付きリクエストで指定された保存された応答のいずれも適切でないことを示します。代わりに、キャッシュは完全な応答を使用してリクエストを満たさなければなりません (MUST)。キャッシュはそのような完全な応答を保存してもかまいませんが (MAY)、その制約の対象となります (セクション3を参照)。

  • ただし、応答の検証を試みているときにキャッシュが5xx (Server Error) 応答を受信した場合、その応答をリクエストクライアントに転送するか、サーバーが応答に失敗したかのように振る舞うことができます。後者の場合、キャッシュはそうすることに関する制約の対象となる以前に保存された応答を送信してもかまいません (MAY) (セクション4.2.4を参照)、または検証リクエストを再試行してもかまいません。

4.3.4 Freshening Stored Responses upon Validation (検証時の保存された応答の更新)​

キャッシュが304 (Not Modified) 応答を受信した場合、新しい情報で更新するのに適した保存された応答を識別し、それを実行する必要があります。

更新する保存された応答の初期セットは、このリクエストに対して選択できた可能性のあるものです。つまり、セクション4の要件を満たすものですが、新鮮である、古い状態で提供することが許可されている、または検証されたばかりであるという最後の要件を除きます。

保存された応答の初期セットは、次の最初に一致するものによってさらにフィルタリングされます:

  • 新しい応答に1つ以上の「強力なバリデータ (Strong Validators)」([HTTP]のセクション8.8.1を参照) が含まれている場合、これらの強力なバリデータのそれぞれが更新のために選択された表現を識別します。初期セット内の、同じ強力なバリデータのいずれかを持つすべての保存された応答が更新のために識別されます。初期セット内のいずれにも同じ強力なバリデータの少なくとも1つが含まれていない場合、キャッシュは新しい応答を使用して保存された応答を更新してはなりません (MUST NOT)。

  • 新しい応答に強力なバリデータが含まれていないが、1つ以上の「弱いバリデータ (Weak Validators)」が含まれており、それらのバリデータが保存された応答の初期セットの1つに対応している場合、それらの一致する保存された応答の最新のものが更新のために識別されます。

  • 新しい応答にいかなる形式のバリデータも含まれていない場合 (クライアントがLast-Modified応答ヘッダーフィールド以外のソースからIf-Modified-Sinceリクエストを生成する場合など)、初期セットに保存された応答が1つだけあり、その保存された応答にもバリデータがない場合、その保存された応答が更新のために識別されます。

識別された各保存された応答について、キャッシュはセクション3.2に従って、304 (Not Modified) 応答で提供されたヘッダーフィールドでそのヘッダーフィールドを更新しなければなりません (MUST)。

4.3.5 Freshening Responses with HEAD (HEADを使用した応答の更新)​

HEADメソッドへの応答は、GETで行われた同等のリクエストと同一ですが、コンテンツは送信されません。HEAD応答のこの特性は、より効率的な条件付きGETリクエストメカニズムが利用できない場合 (保存された応答にバリデータが存在しないため)、またはコンテンツが変更されている場合でもコンテンツの送信が望ましくない場合に、キャッシュされたGET応答を無効にしたり更新したりするために使用できます。

キャッシュがターゲットURIのインバウンドHEADリクエストを行い、200 (OK) 応答を受信した場合、キャッシュはそのリクエストに対して選択できた可能性のある各保存されたGET応答を更新または無効にすべきです (SHOULD) (セクション4.1を参照)。

選択できた可能性のある各保存された応答について、保存された応答とHEAD応答が受信したバリデータフィールド (ETagおよびLast-Modified) に一致する値を持ち、HEAD応答にContent-Lengthヘッダーフィールドがある場合、その値が保存された応答の値と一致する場合、キャッシュは以下に説明するように保存された応答を更新すべきです (SHOULD)。それ以外の場合、キャッシュは保存された応答を古いと見なすべきです (SHOULD)。

キャッシュがHEAD応答からのメタデータで保存された応答を更新する場合、キャッシュはHEAD応答で提供されたヘッダーフィールドで保存された応答を更新しなければなりません (MUST) (セクション3.2を参照)。

4.4 Invalidating Stored Responses (保存された応答の無効化)​

PUT、POST、またはDELETEなどの安全でないリクエストメソッド ([HTTP]のセクション9.2.1を参照) は、オリジンサーバーの状態を変更する可能性があるため、介在するキャッシュはコンテンツを最新の状態に保つために保存された応答を無効にする必要があります。

キャッシュが安全でないリクエストメソッド (安全性が不明なメソッドを含む) に対する非エラーステータスコード応答を受信した場合、キャッシュはターゲットURI ([HTTP]のセクション7.1を参照) を無効にしなければなりません (MUST)。

キャッシュが安全でないリクエストメソッド (安全性が不明なメソッドを含む) に対する非エラーステータスコード応答を受信した場合、キャッシュは他のURIを無効にしてもかまいません (MAY)。特に、LocationおよびContent-Location応答ヘッダーフィールド (存在する場合) のURIは無効化の候補です。他のURIは、このドキュメントで指定されていないメカニズムによって発見される可能性があります。ただし、無効にするURIの起源 ([HTTP]のセクション4.3.1を参照) がターゲットURI ([HTTP]のセクション7.1を参照) の起源と異なる場合、キャッシュはこれらの条件下で無効化をトリガーしてはなりません (MUST NOT)。これにより、サービス拒否攻撃を防ぐのに役立ちます。

「無効化 (Invalidate)」とは、キャッシュが、ターゲットURIが指定されたURIと一致するすべての保存された応答を削除するか、それらを「無効 (Invalid)」としてマークし、後続のリクエストへの応答として送信する前に必須の検証が必要であることを示すことを意味します。

「非エラー応答 (Non-Error Response)」とは、2xx (Successful) または3xx (Redirection) ステータスコードを持つ応答です。

これは、すべての適切な応答のグローバルな無効化を保証するものではないことに注意してください。状態変更リクエストは、通過したキャッシュ内の応答のみを無効にします。

に最終更新