Revalidate without re-downloading
Conditional requests let a client ask “has this changed?” and get back a tiny
304 Not Modified instead of the whole body. They also power optimistic
concurrency, so two clients don’t silently overwrite each other. This reference
covers the validator headers, the strong-versus-weak comparison rules, and the
304 flow — plus a comparator for two ETags.
How it works
A response advertises validators:
ETag: "33a64df5"
Last-Modified: Tue, 10 Jun 2026 12:00:00 GMT
The client echoes them on the next request:
If-None-Match: "33a64df5"
If-Modified-Since: Tue, 10 Jun 2026 12:00:00 GMT
If unchanged, the server replies 304 Not Modified with no body. Strong
comparison (used by range requests) requires both ETags present, neither weak,
and identical. Weak comparison (used by If-None-Match for cache
revalidation) treats W/"x" and "x" as matching. For writes, If-Match with
the last-known ETag yields 412 Precondition Failed if the resource moved on,
preventing lost updates.
Tips and notes
- Prefer strong ETags unless your representation legitimately changes byte-for-byte.
- ETag beats
Last-Modifiedfor precision (sub-second changes, content hashing). - Use
If-Match/If-None-Match: *to make creates and replaces idempotent. - A
304should still carry headers likeETag,Cache-ControlandVary.