5. Evaluation (評価)

以下で除外される場合を除き, 受信者のキャッシュまたはオリジンサーバーは, 通常のリクエストチェックを正常に実行した後, リクエストコンテンツ (存在する場合) を処理する直前, またはリクエストメソッドに関連付けられたアクションを実行する直前に, 受信したリクエストの前提条件を評価しなければなりません (MUST)。サーバーは, これらの条件なしで同じリクエストへの応答が 2xx (Successful) または 412 (Precondition Failed) 以外のステータスコードになる場合, 受信したすべての前提条件を無視しなければなりません (MUST)。言い換えれば, 条件付きリクエストでは, リダイレクトと失敗が前提条件の評価よりも優先されます。

ターゲットリソースのオリジンサーバーではなく, ターゲットリソースへのリクエストのキャッシュとして機能できないサーバーは, この仕様で定義された条件付きリクエストヘッダーフィールドを評価してはならず (MUST NOT), リクエストが転送される場合はそれらを転送しなければなりません (MUST)。生成クライアントは, 現在の表現を提供できるサーバーによってそれらが評価されることを意図しているためです。同様に, CONNECT, OPTIONS, TRACE など, 選択された表現の選択または変更を伴わないリクエストメソッドと共に受信された場合, サーバーはこの仕様で定義された条件付きリクエストヘッダーフィールドを無視しなければなりません (MUST)。

プロトコル拡張は, 前提条件が評価される条件またはその評価の結果を変更できることに注意してください。例えば, "immutable" キャッシュ制御ディレクティブ ([RFC8246] で定義) は, 再検証なしで 304 (Not Modified) 応答を返せるように事前評価チェックを変更します。

条件付きリクエストヘッダーフィールドは HEAD メソッドと共に使用可能として定義されていますが (HEAD のセマンティクスを GET と一致させるため), 条件付き HEAD を送信する意味はありません。成功応答は 304 (Not Modified) 応答とほぼ同じサイズであり, 412 (Precondition Failed) 応答よりも有用だからです。