ETag & Conditional Request Reference

ETag, If-None-Match, If-Modified-Since headers with strong/weak comparison.

Reference for HTTP conditional request headers with strong vs weak ETag semantics, the 304 Not Modified flow, optimistic concurrency via If-Match and a live ETag comparator.

What is the difference between a strong and weak ETag?

A strong ETag (like "abc") guarantees byte-for-byte identity, so it can be used for range requests and caching. A weak ETag (prefixed W/, like W/"abc") only guarantees semantic equivalence — the content means the same thing but may differ byte-for-byte, e.g. after recompression.

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-Modified for precision (sub-second changes, content hashing).
  • Use If-Match/If-None-Match: * to make creates and replaces idempotent.
  • A 304 should still carry headers like ETag, Cache-Control and Vary.