httpcachinghttp-headersbrowser-cacheetag

Etag: weak vs strong example


I have been reading about Etags, and I understand that there are 2 ways of generating an Etag, weak and strong. Weak Etags are computationally easier to generate than strong ones. I have also come to know that Weak Etags are practically enough for most use cases.

from MDN

Weak validators 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.

another snippet:

Weak Etag values of two representations of the same resources might be semantically equivalent, but not byte-for-byte identical.

I am finding it hard to understand what does it mean for a resource to be semantically similar but not byte by byte same ? It would be great to see some examples.

EDIT: found an example here, but i don't get it:

Weak Validation: The two resource representations are semantically equivalent, e.g. some of the content differences are not important from the business logic perspective e.g. current date displayed on the page might not be important for updating the entire resource for it.

Is it like while generating the Etag, you can decide that the changes in content are not important for the functionality (for e.g. a css property change for font-size) and respond with 304 ? If yes, then when is the resource updated on the browser, as I guess as long as the Etag is the same , the browser would not get the latest version. In this case it might mean that when a major change happens and a new Etag is created, the css property change would only then be sent to the browser along with the major change.


Solution

  • My suggestion is to look at the specification, RFC 7232, section 2.1. It's only a couple pages long and may answer all of your questions.

    You asked for examples, here are some from the specification:

    That last one represents what is probably the most common use of weak ETags: servers converting strong ETags into weak ones when they gzip the content. Nginx does this, for example.

    The specification also explains when to change a weak ETag:

    An origin server SHOULD change a weak entity-tag whenever it considers prior representations to be unacceptable as a substitute for the current representation.

    In other words, it's up to you to decide if two representations of a resource are acceptable substitutions or not. If they are, you can improve caching performance by giving them the same weak ETag.