ETag

An ETag (entity tag) is an HTTP response header introduced in RFC 2616 and now defined by RFC 9110. The server emits an opaque token that identifies a specific version of the resource at a given URL: `ETag: "33a64df5"`. The token's internal structure is implementation-defined and might be a content hash, a database revision number, or a counter. Clients store ETags alongside cached responses and send them back on revalidation in the If-None-Match request header. If the server's current ETag matches, it returns 304 Not Modified with no body, and the client reuses its cached representation. If the tag has changed, the server returns a fresh 200 response. ETags also work with conditional writes via If-Match, which lets a client update a resource only if its tag has not changed in the meantime — a common pattern for optimistic concurrency control in REST APIs. ETags exist in two flavors. A strong validator guarantees byte-for-byte equivalence between representations and is required for byte-range requests. A weak validator, prefixed with `W/`, only asserts semantic equivalence — two representations with the same weak ETag may differ in encoding, whitespace, or minor metadata while being interchangeable for the client. Strong comparison demands both ETags be strong and match exactly; weak comparison ignores the W/ prefix. ETags pair naturally with HTTP Caching and complement Last-Modified, which uses an HTTP-date and the If-Modified-Since header. When both are present, RFC 9111 specifies that If-None-Match takes precedence. A common pitfall is generating different ETags for the same content across server replicas, which destroys cache hit rates behind load balancers; the fix is making ETag generation deterministic from the resource itself.