ETag
The "ETag" header field provides an identifier that uniquely identifies the selected representation, typically used for caching and conditional requests. It is used to distinguish between different representations of the resource that may be selected and the changes to those resources over time.
This entity-tag is used for making subsequent requests in the If-Match and If-None-Match headers.
Writing responses (origin servers)
200 (OK) responses
Use ETag
whenever it is feasible to generate one; especially if the server expects to serve the same document to the client in the future. If clients implement ETag support and it is the case the document hasn't changed, the server can avoid re-sending the document contents in response to that request.
The ETag is computed just after the server has determined which particular representation it will send to the client, but before it actually has to generate the payload. The purpose of the ETag is to avoid generating and sending a response if the client has a stored previous response; so the ETag must be a function of any variables that would cause the response payload to change. The metadata may change, so long as the payload does not(for example, two documents with different media types may share the same ETag if their contents are the same). Often, servers will compute an ETag by hashing the negotiated variant and last-modified values together. For documents on a filesystem, servers may hash a salt, filename, mtime (high-precision if available), and document size together. The document size is included so that data appended will also change the ETag, even if the mtime does not. For documents generated by a function, the ETag might be generated by hashing the function name and function parameters together, computed before calling the function.
If the document would otherwise be unable to generate a strong ETag, it may instead choose to generate a weak ETag. Weak ETags are a weak validator allowed to change in insignificant ways while still matching. For example, differences is lossy compression, a different encoding of the same image, or real-time data that has not significantly changed (for some statistical definition of significant).
Servers should send both Last-Modified and ETag.
Servers must include this header even in a 304 (Not Modified) response.
The ETag syntax has previously been defined as a quoted-string; so backslashes should be avoided, and should also be a valid quoted-string production if used.
201 (Created) responses
The ETag header in a 201 (Created) response refers to the ETag of the newly created resource. See 201 (Created) for additional information.
Reading responses (user agents)
User agents may use a response with an ETag to update the local cache. See If-None-Match and the caching rules for more information.
Overview table
- Name
- ETag
- Description
- Specifies an identifier for the selected representation
- Direction
- Request
- Specification
- RFC 9110: HTTP Semantics §8.8.3. ETag
Syntax
ETag = entity-tag
entity-tag = [ weak ] opaque-tag
weak = %x57.2F ; "W/", case-sensitive
opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text
; VCHAR except double quotes, plus obs-text
Matching
ETags can be matched with one of two algorithms:
Strong comparison
With a strong comparison, the ETags must match, and neither can be a weak ETag.
Weak comparison
With a weak comparison, the ETags merely need to match, and the weak-tag, if any, is ignored.
History
- 1999-06: RFC 2616 §14.19. ETag
- 2014-06: RFC 7232 §2.3. ETag
- 2022-06: RFC 9110 §8.8.3. ETag