What is, and how does it work, an ETag

Briefly, ETag is an HTTP mechanism for conditional cache validation.

The idea is to serve content to be cached with an identifier (usually a hash or version number). The client then starts using this identifier to ask the server if the content has changed.

Example

The request:

GET /Trj17.png HTTP/1.1
Host: i.stack.imgur.com

Receive the image with the header ETag :

HTTP/1.1 200 OK   
Content-Type: image/png
Content-Length: 61404
ETag: "a5ea8bbcc437de9787e9a87ef6ef690a"

corpo da imagem

The client then caches this image. When the user requests the image again the client can use the identifier to "ask" the server if the cached version is still valid:

GET /Trj17.png HTTP/1.1
Host: i.stack.imgur.com
If-None-Match: "a5ea8bbcc437de9787e9a87ef6ef690a"

If the version is still valid, the server returns a response with code 304, indicating that it is safe for the client to use the cached version:

HTTP/1.1 304 Not Modified
ETag: "a5ea8bbcc437de9787e9a87ef6ef690a"

In case the image has changed the server responds with code 200, the new version of the image and a new ETag.

In this way, we consider ETag a content-based cache validation mechanism, as opposed to the pair of Last-Modified and If-Modified-Since headers that configure a time-based validation mechanism.

Both validation mechanisms are complementary to the Cache-Control and Expires headers that basically tell the client whether or not to cache a feature and when.

In etag is basically an identifier for a response to a content negotiation. If the content varies, the Etag varies, not necessarily the address of the requested resource varies.

When you make a request, it can vary the response according to the context. A simple example would be if you make a request to a text file, time with Gzip support and another time without support, the requested file as well as the URL of the resource are the same, however the etag will vary because the request varied.

If you want to have a more formal definition, you can refer to the RFCs that implement the protocols:

link

Note: The example was taken from there.

If you intend to work directly with the implementation of the protocols strongly recommend that you start with the RFCs, each webserver implements support for specific versions of the protocols, you can check this in the webserver documentation itself. There are always additional configurations on the server to enable or disable a particular feature, so 'sniffing' a set of requests does not necessarily make you discover support for a given webserver, it actually shows you what the current configuration of the given webserver instance supports .

Taking into account that the etag of a particular file (which you did not specify the type) may vary, you will not find an etag for a file, will find an etag for a particular request context to a file .

Unless this is a mistake, this can vary depending on the OS where the webserver is installed, even for the same Webserver version, since the file statuses are returned to the webserver by the OS, which only then returns the changes to the request , see the apache documentation and search for etag.

link

As I do not know the purpose of your framework, I can not suggest anything specific.