ETag HTTP response header is an identifier for a
specific version of a resource. It lets caches be more efficient and save bandwidth, as
a web server does not need to resend a full response if the content has not changed.
Additionally, etags help prevent simultaneous updates of a resource from overwriting
each other ("mid-air collisions").
If the resource at a given URL changes, a new
Etag value must be
generated. A comparison of them can determine whether two representations of a resource
are the same. Etags are therefore similar to fingerprints, and might also be used for
tracking purposes by some servers. They might also be set to persist indefinitely by a
|Header type||Response header|
|Forbidden header name||no|
ETag: W/"<etag_value>" ETag: "<etag_value>"
'W/'(case-sensitive) indicates that a weak validator is used. Weak etags are easy to generate, but are far less useful for comparisons. Strong validators are ideal for comparisons but can be very difficult to generate efficiently. Weak
ETagvalues of two representations of the same resources might be semantically equivalent, but not byte-for-byte identical. This means weak etags prevent caching when byte range requests are used, but strong etags mean range requests can still be cached.
- Entity tag uniquely representing the requested resource. They are a string of ASCII
characters placed between double quotes, like
"675af34563dc-tr34". The method by which
ETagvalues are generated is not specified. Often, a hash of the content, a hash of the last modification timestamp, or just a revision number is used. For example, MDN uses a hexadecimal hash of the wiki article content.
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4" ETag: W/"0815"
With the help of the
ETag and the
If-Match headers, you
can detect mid-air edit collisions.
For example, when editing MDN, the current wiki content is hashed and put into an
Etag in the response:
If the hashes don't match, it means that the document has been edited in-between and a
Precondition Failed error is thrown.
Another typical use of the
ETag header is to cache resources that are
unchanged. If a user visits a given URL again (that has an
ETag set), and
it is stale (too old to be considered usable), the client will send the value
ETag along in an
If-None-Match header field:
The server compares the client's
ETag (sent with
If-None-Match) with the
ETag for its current version of the
resource, and if both values match (that is, the resource has not changed), the server
sends back a
Not Modified status, without a body,
which tells the client that the cached version of the response is still good to use
|RFC 7232, section 2.3: ETag||Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests|
BCD tables only load in the browser