条件付きリクエストは、比べる役をサーバに渡す

「Webを支えるソフトウェア」コースの「キャッシュはどこに効くのか — 鍵と鮮度」で、失効したキャッシュは捨てられたのではなく、検証に成功すれば復活できると見ました。この回で扱うのは、その検証の手段です。

RFC 9110 §13 は、条件付きリクエストの用途を1段落に2つ並べています。

Conditional GET requests are the most efficient mechanism for HTTP cache updates [CACHING]. Conditionals can also be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem: one client accidentally overwriting the work of another client that has been acting in parallel.

どちらの用途でも、比べる役はサーバにあります(§13.1)。

Each precondition defined below consists of a comparison between a set of validators obtained from prior representations of the target resource to the current state of validators for the selected representation (Section 8.8).

比べるのは「前に受け取った検証子」と「今の検証子」です。今の版を最終的に決めるのはオリジンサーバで、クライアントではないので、クライアントは前の札を送り返し、比べる役はサーバが持ちます。札の作り方もサーバが決めます(§8.8.3.1)。

Since the value is opaque, there is no need for the client to be aware of how each entity tag is constructed.

札を送り返してサーバに比べさせる仕組みは、書き込みにも使えます。向きは逆で、If-None-Match は「札が違えば実行する」、If-Match は「札が同じときだけ実行する」です。

比べ方も変わります。§13.1.2 は If-None-Match に弱い比較を、§13.1.1 は If-Match に強い比較を、どちらも MUST で課しています。

An origin server MUST use the strong comparison function when comparing entity tags for If-Match (Section 8.8.3.2), since the client intends this precondition to prevent the method from being applied if there have been any changes to the representation data.

キャッシュの検証は意味が同じなら十分ですが、上書きを防ぐには少しの変化でも止めなければなりません。強い比較では W/ の付いた札はどれとも一致しません。

条件が偽だったときの縛りの強さも違います。

ヘッダ          実行        返す応答
If-None-Match   MUST NOT    GET/HEAD は 304、他は 412(MUST)
If-Match        MUST NOT    412 で知らせてよい(MAY)
                          適用済みに見えるなら 2xx でもよい(MAY)

If-Match で「実行しない」は MUST ですが、「412 を返す」は MAY です。