ETag and conditional requests

What it means

An HTTP ETag is an opaque representation validator. A client can send it back with a conditional request to avoid receiving an unchanged representation or to prevent an unintended write. If-None-Match uses weak comparison for conditional retrieval and can produce 304 Not Modified for matching GET/HEAD; If-Match uses strong comparison to protect a modification and can produce 412 Precondition Failed. Weak validators prefixed W/ do not satisfy strong comparison.

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.

Primary protocol documentation provides the underlying rules; the interactive state is only a synthetic illustration.

In practice

For collaborative editing or API updates, read the server's actual ETag/precondition contract and test a normal fetch, one update and a concurrent stale update in an isolated environment. Do not assume all APIs support PUT, return ETags or choose validators identically. Stop if a client gets 412 or a version mismatch; refetch state and resolve conflicts instead of retrying writes without conditions. Keep an application-level rollback/restore mechanism for modifications.

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

An ETag is an opaque representation validator, not necessarily a content hash. If-None-Match supports weak comparison for cache validation; If-Match requires strong comparison for guarded writes. A successful virtual update changes the validator, so a later stale precondition must be tested against the new state, not replayed as success.