ETag (for entity tag) is a header field introduced in HTTP 1.1. It is used to determine changes to the requested resource and is mainly used for browser caching, i.e. to avoid redundant data transfers. The ETag value is an arbitrary string enclosed by quotation marks, which can also be indicated as a weak ETag by the prefix “”. RFC-7232 states that ETags should be content-coding aware.
1 2 3 4 | ETag: "123-a" – for no Content-Encoding ETag: "123-b" – for Content-Encoding: gzip "123456789" – A strong ETag validator W/"123456789" – A weak ETag validator |
Strong ETag
A strong ETag can only be managed by several entities of a resource if they are absolutely identical (bit for bit).
---
Weak ETag
A weak ETag (indicated by a W/ prefix) may be managed by several entities of a resource if they are equivalent to each other, i.e. do not differ significantly semantically from each other. Often, the generation of the ETag value is based on the hash of the contents of the resource or the time of the last modification.
The first time a resource is requested, the server sends an ETag value specific to that resource in the header field, which is stored locally by the client along with the resource. When requesting the same resource again, the client sends the previously stored ETag value in the header field. On the server side, the sent ETag value is now compared with the current one and, if it matches, answered with the status code 304 (see HTTP error codes). In this case, the data of the resource is not sent and the client uses the locally stored data.
If implemented incorrectly, the ETag can have a negative impact: For example, if the ETag is generated from the inode of the document to be delivered, this value is only valid on this system. If the document is now delivered from several servers (e.g. for server load balancing), a new request from the client can be processed by another server with a different ETag value, which in turn results in the transfer of the same file despite ETag. For this reason, it is recommended not to use the inode when generating the ETag value.
For example, a hash value about the contents of the file or a unique version number of the file should be used to generate the ETag. In addition, users can be identified by ETag when a web server generates client-specific ETags.
The If-Modified-Since headers are nearly as good, and do not suffer from above problems. If-Modified-Since allows a 304 Not Modified to be returned if content is unchanged:
1 | If-Modified-Since: Wed, 23 Nov 2023 19:43:31 GMT |
If-None-Match allows a 304 Not Modified to be returned if content is unchanged:
1 | If-None-Match: "aa12bb34...." |
