ETags and conditional requests: reading a cache validation exchange
An ETag identifies a representation for comparison. The request method, comparison rule and stored response determine what a validation result means.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
ETag validation compares a stored representation with a server expectation; a matching conditional GET can reuse saved content through a 304 response.
Conceptual illustration, not a measured network exchange.
A validator is different from a freshness clock
An ETag gives a representation an opaque identifier for comparison; it is not a clock or an authorization token. A response can become stale without its content changing. Freshness asks whether a stored response may be reused under the applicable caching rules; validation asks whether a stored representation can still be used after a check. HTTP semantics
Keep those questions separate when reading a network log. An elapsed freshness period does not, by itself, demonstrate that an editor published new content. Equally, seeing the same tag twice does not tell you which cache served the response or why a request was made. Start with the URL, request method, cache directives and validator, rather than treating one field as the complete history of the response.
Read weakness without inventing the tag formula
The ETag value is quoted and opaque. W/ marks a weak validator: semantic equivalence can be sufficient without byte identity. It does not prescribe how the server generated the tag, and whitespace equivalence is not automatic. A strong validator has stronger representation identity requirements, which matter for uses such as byte-range handling. ETag interpretation
For an illustrative documentation exercise, imagine two stored versions labelled A and B. Those labels are explanatory names, not actual ETags. Ask whether the service intends to distinguish their bytes or treat their meaning as equivalent. The reader cannot answer that merely by guessing that the visible tag looks like a hash. Record the server’s stated rule if available; otherwise leave its generation mechanism unknown. No filesystem variable or digest algorithm follows from the syntax alone.
The header and method determine the condition
If-None-Match uses weak comparison even when the supplied tag is strong. A matching entity-tag makes the If-None-Match precondition false: GET or HEAD then uses 304, while other methods use 412. If-Match uses strong comparison; it is a separate precondition, not simply an interchangeable inverse. A satisfied precondition does not promise success regardless of authorization or other request processing. Conditional rules If-Match definition
A reader comparing two logs should therefore write down the method before interpreting the tag. In a hypothetical pair, a retrieval and a modification request can carry similar-looking conditions but require different outcomes. Do not copy the explanation of the retrieval into the modification case. For a concurrent-edit example, note which representation the editor originally saw and which expectation was sent; the presence of a header alone does not prove that the application handled every conflict correctly.
304 reuses a body and updates eligible metadata
A 304 has no response content. A cache can identify eligible stored responses and update them using supplied fields under the caching rules, including their exceptions; it then reuses stored content. RFC 9110 requires a specified subset of header fields that would accompany the corresponding 200 response, not all its fields. This is not a blanket replacement of every header, a disk-only operation, or an automatic new lifetime. 304 response Stored-response update rules
Consider an illustrative log with an earlier body-bearing response and a later 304. Read them together: the later exchange cannot supply a missing stored body. Write separate notes for the body retained and the metadata received. If the earlier response is unavailable, the log does not let you reconstruct the content from the 304 alone. A missing payload on that line is the expected shape of validation, rather than evidence that an empty document was served to the reader.
An institutional expert perspective on cache policy
MDN’s specialist caching guide distinguishes private caching from shared caching and separates no-cache from no-store. In their unqualified forms, no-cache requires validation before reuse, no-store prohibits storage, and private restricts shared-cache storage rather than banning browser caching. Cookies alone do not establish the private directive. Cache policy guidance
Use that distinction as a reading checklist: which response is stored, which cache might hold it, what allows reuse, and what triggers checking? Document uncertainty where the capture does not show the cache or earlier response. A 304 does not certify that nothing changed anywhere on a server, and an ETag does not independently certify the safety of the content. The example workflows here are interpretation exercises, not measurements of a CDN or a guarantee of bandwidth, latency or conflict prevention.