ETag and conditional requests

What it means

An ETag is a validator for a selected representation of a resource. Clients can use it to ask whether a stored response is still current or to guard a write against unintended overwrites. If-None-Match and If-Match have different preconditions and comparison rules; the same tag does not imply identical HTTP outcomes for GET and PUT. HTTP conditionals

Try it

Simulation — compare validators. Set the stored client tag and current resource tag to "v1" and request GET with If-None-Match: the result is 304 without response content. Change the current tag to "v2" for a full 200 representation. Switch to PUT with If-Match and try the weak W/"v1": it fails a strong check. Run a matching strong guarded write and inspect the new virtual validator; a later stale write should fail. Reset discards the virtual update.

How the mechanism works

A server chooses opaque entity-tag values. Clients must not assume an ETag is always a file hash, timestamp or portable identifier for a resource across representations. Weak tags allow semantically equivalent representations under the relevant comparison; strong comparison demands matching opaque tags without weakness. The same literal-looking tag can produce different conditional behavior depending on the header and method.

On a matching If-None-Match GET, the server can send 304 and selected representation metadata; the client uses a previously stored body according to cache rules. For a conditional PUT, a failing If-Match protects against overwriting a changed version and normally produces 412. An accepted update can change the ETag; repeating the previous strong precondition then becomes stale. The exercise distinguishes the status of a response from the state of its virtual representation.

A stale editor attempts a conditional PUT

An editor retrieves version "v1" and saves it with If-Match: "v1". In this synthetic resource, the strong match permits the first conditional PUT and advances the stored validator to "v3". Replay the old If-Match: "v1" and it now fails with 412 Precondition Failed. The example changes only local model state; it performs no HTTP write.

Contrast that with If-None-Match: "v1" on GET when current content is still tagged "v1": a weak comparison can yield 304 Not Modified and the client reuses its already held representation. A W/ prefix matters for strong comparison. Do not assume a real API supports these operations unless its contract says so.

A weak validator is useful for retrieval, not a write lock

Suppose the current selected representation has weak ETag W/"v1". For a conditional GET with If-None-Match: W/"v1", the weak comparison can match and permit a 304 Not Modified response under the applicable rules. The same weak tag in If-Match on a state-changing request does not satisfy the strong comparison used to protect a write. A client must not assume that successful cache validation implies protection against overwriting concurrent work.

The fixture demonstrates only the selected validator comparisons and local resource revisions. Real services might omit ETags, generate them from different representations or impose additional write preconditions. On a 412, STOP and fetch the current state to resolve the conflict instead of blindly resubmitting the old body. Conditional requests

In practice

Record the exact selected representation, method, validator and precondition sent on the wire. For an authorized edit, read current state and use appropriate conditional writes; after 412, inspect the new state instead of blindly retrying the old payload. An ETag need not be a cryptographic hash and should not be treated as an integrity or authentication signature.

Limits and common mistakes

This model allows just GET, HEAD and PUT with If-None-Match/If-Match and a few fixed ETags. It does not cover wildcard conditions, full precondition precedence, partial representations, all response headers or actual persistence. Its write is local to memory only.

Key takeaways

Cache validators and concurrency guards serve different purposes. Select the correct precondition for the intended method, and respect a 412 as evidence that the previously observed state cannot be assumed current.