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)レスポンスを受信すると、RFC 7232のセクション4.1に従い、304レスポンスで提供されたヘッダーフィールドで保存されたレスポンスのヘッダーフィールドを更新しなければならない (MUST)。

キャッシュはまた、検証を引き起こしたリクエストを満たすために更新された保存されたレスポンスを使用しなければならず (MUST)、他のリクエストを満たすためにそれを使用してもよい (MAY)。

ヘッダーフィールド値を更新する場合、キャッシュは保存されたレスポンス内のwarn-code 1xxを持つすべてのWarningヘッダーフィールドを削除しなければならず (MUST)、304レスポンス内のすべてのWarningヘッダーフィールドを更新された保存されたレスポンスに追加しなければならない (MUST)(セクション5.5参照)。

4.3.5. Freshening Responses via HEAD (HEADによるレスポンス更新)

HEADメソッドへのレスポンスは、GETで行った同等のリクエストと同一であるが、ボディが欠けている点が異なる。HEADレスポンスのこの特性により、キャッシュはレスポンスコンテンツ全体を転送せずに保存されたレスポンスを更新できる。したがって、HEADレスポンスに保存されたGETレスポンスと一致するLast-ModifiedおよびETagフィールド値がある場合、キャッシュはHEADレスポンスを使用してキャッシュされたGETレスポンスを更新してもよい (MAY)。

HEADレスポンスを使用して保存されたレスポンスを更新する場合、キャッシュはHEADレスポンスで提供されたヘッダーフィールド値で保存されたレスポンスのヘッダーフィールドを更新しなければならない (MUST)。

4.4. Invalidation (無効化)

キャッシュ無効化の目的は、実際のレスポンス値(ヘッダーフィールドではない)が無効化されたレスポンスと大きく異なる可能性が高いレスポンスを排除し、2つが代替として提示される場合の混乱を回避することである。

キャッシュが、保存されたレスポンスの更新につながる可能性のあるメソッドを含むリクエストを受信した場合(例えば、PUT、POST、またはDELETE; [RFC7231] のセクション4.2.1を参照)、有効なリクエストURI([RFC7230] のセクション5.5)のすべての保存されたレスポンス、およびLocationおよびContent-Locationレスポンスヘッダーフィールド(存在する場合)内のURIのすべての保存されたレスポンスを無効と見なさなければならない (MUST)。

ただし、レスポンスステータスコードがリダイレクトであり、そのURI内のホストコンポーネントが有効なリクエストURIのホストと異なる場合、キャッシュはLocationまたはContent-Locationレスポンスヘッダーフィールドに表示されるURIを無効化してはならない (MUST NOT)。

キャッシュは、ターゲットリソースの状態が変更された可能性があることを意味するセマンティクスを持つメソッドへのリクエストに対する非エラーレスポンスを受信した場合(例えば、PUT、POST、DELETE、およびPATCH)、有効なリクエストURI([RFC7230] のセクション5.5)を無効化しなければならない (MUST)。