HTTP cache validation (source code)

= HTTP cache validation
{c}

<HTTP cache validation> checks whether a stored <HTTP response> remains suitable for reuse, commonly by sending an <HTTP conditional request> containing a validator such as an <entity tag>. It supports reusing stored representation data while checking with a server whether the relevant state has changed.<HTTP Caching>[§4.3, Validation; §4.3.1, Sending a Validation Request]{ref}

Validation and <HTTP freshness> answer different questions. A stored response may still be fresh according to its lifetime and age, allowing reuse under the applicable rules without this exchange. A response that is no longer fresh is not thereby known to have different content at the origin: validation can establish that reuse remains appropriate.<HTTP Caching>[§4.2, Freshness; §§4.3.3–4.3.4, validation response and freshening]{ref}

Suppose a cache stores a successful `/manual` response with a $12000$-octet body and <entity tag> `"manual-4"`. Assume that it is otherwise eligible for reuse after successful validation. A later `GET` sends `If-None-Match: "manual-4"`. If the selected <HTTP representation> still matches, the origin returns `304` without a representation body. The cache identifies the matching stored response, updates its fields according to the validation rules, and reuses its stored data.<HTTP Semantics>[§13.1.2, weak comparison for If-None-Match and GET/HEAD outcome]{ref}<HTTP Caching>[§4.3.4, selecting stored responses and updating their fields; §3.2, field-update rules]{ref}

In that unchanged branch, the origin avoids retransmitting the $12000$ representation-body octets. The validation request and response still have a cost; the body count alone is not a measurement of total network savings. Nor is `304` an empty replacement document: the useful data are the body already held by the cache.

If the selected representation changed, an otherwise successful validation request can instead receive a full response with its new data. The cache uses that response to satisfy the request and may store it subject to the ordinary storage constraints.<HTTP Caching>[§4.3.3, handling full and 304 validation responses]{ref} A validator alone does not make every stored response reusable: selection inputs, applicable cache controls and the result of validation still matter.

The comparison rule also matters. `If-None-Match` uses weak <entity tag> comparison, so <HTTP cache validation> can accept the server's declared equivalence through a <weak entity tag>. An update requiring an exact precondition through `If-Match` instead uses <strong entity tag> comparison.<HTTP Semantics>[§§13.1.1–13.1.2, respective comparison functions]{ref}