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

4.3. 検証 (Validation)

キャッシュが要求されたURIに対して1つ以上の保存されたレスポンスを持っているが、それらのいずれも提供できない場合（例えば、新鮮ではない、またはリクエストディレクティブが禁止しているため）、転送されたリクエストで条件付きリクエストメカニズム [RFC7232] を使用して、オリジンサーバーに使用する有効な保存されたレスポンスを選択する機会を与えることができる。このプロセスで保存されたメタデータを更新するか、保存されたレスポンスを新しいレスポンスで置き換える。このプロセスは、保存されたレスポンスの「検証」または「再検証」と呼ばれる。

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

検証用の条件付きリクエストを生成する場合、キャッシュは、満たそうとしているリクエストから開始するか、（独立してリクエストを開始する場合）メソッド、ターゲットURI、および関連するリクエストヘッダーフィールドをコピーして、保存されたレスポンスを使用してリクエストを合成する。

次に、1つ以上の前提条件ヘッダーフィールドでそのリクエストを更新する。これらには、検証される保存されたレスポンスから取得されたバリデータメタデータ（[RFC7232] のセクション2.3）が含まれる。通常、これには保存されたレスポンスのLast-ModifiedおよびETagフィールド値が含まれる。

次に、キャッシュは条件付きリクエストをオリジンサーバー（または、Viaヘッダーフィールドにリストされている下流のキャッシュ）に送信できる。

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

リクエストチェーン内の各クライアントは独自のキャッシュを持つ可能性があるため、中間層のキャッシュが他の（アウトバウンド）キャッシュから条件付きリクエストを受信することは一般的である。同様に、一部のクライアントには時計のずれやその他の問題があり、それらを理解せずに条件付きリクエストを生成する可能性があるか、またはそのようなリクエストはHTTP基盤ライブラリを使用する実装によって生成される可能性がある。

これは、条件付きリクエストに対して304（Not Modified）または412（Precondition Failed）レスポンスを提供することが、クライアントがそのようなレスポンスを理解していること、またはキャッシュされたコピーを持っていること（たとえ持っていても、削除された可能性がある）を意味すると想定できないことを意味する。

キャッシュがバリデータフィールド（If-None-Matchヘッダーフィールドなど）を含むリクエストを受信した場合、条件付きリクエストの対象である保存されたレスポンスが上流から受信した最新の検証レスポンスであることが確実でない限り、304（Not Modified）レスポンスを返してはならない (MUST NOT)。特に、中間層は、保存されたレスポンスのバリデータ（存在する場合、ETagおよびLast-Modifiedフィールド値）が条件付きリクエストで提示されたものとバイト単位で同一であることを検証する必要がある。

キャッシュが保存されたレスポンスを持たない場合（つまり、「オンデマンド」キャッシングを実行している場合）、そのようなチェックを実行する必要はないことに注意すること。

キャッシュは、If-None-MatchまたはIf-Modified-Since前提条件ヘッダーフィールドを含み、その条件がfalseと評価されるリクエストに対して304（Not Modified）レスポンスを送信してはならない (MUST NOT)。これは、クライアントがキャッシュの保存されたレスポンスから有効なレスポンスを構築できないためである。

代わりに、条件付きリクエストを受信し、応答に使用するのに適した保存されたレスポンスを持つキャッシュは、次のいずれかを実行する:

  • 保存されたレスポンスが新鮮である（セクション4.2）場合、または正常に検証された（セクション4.3）場合、304（Not Modified）レスポンスを送信する、または
  • 保存されたレスポンスを検証しようとする独自の条件付きリクエストでリクエストをオリジンサーバーに転送する。

後者の場合、キャッシュは転送されたリクエストにバリデータを含める。転送されたリクエストは、保存されたレスポンスに関連付けられた最新のバリデータセットを使用しなければならない (MUST)。