Weak ETags and on-the-fly gzipping
mlangenberg at gmail.com
Sat Jun 15 12:58:33 UTC 2013
I am serving dynamic requests behind the Nginx HTTP server. HTTP requests
are mostly from mobile HTTP clients. That's is why I care about two things.
1. Do not send the same representation twice: Use ETag caching mechanism.
2. Make better us of available bandwidth: Use Accept-Encoding HTTP
Today I noticed that these two don't match. My application sets the ETag
header in the response, but when I set the 'Accept-Encoding: gzip' in the
request header, nginx clears the ETag header when gzipping on-the-fly.
I understand why this is: If two responses have the same ETag, their bodies
should be byte-for-byte comparable. When the content is gzipped, and
actually modified, this is of course not the case. The gzipped response is
not equal to the non-gzipped response.
That's why there are two ETag validation mechanisms. A strong validation,
used in case of byte-for-byte comparable responses, and a weak validation,
to indicate semantic equivalency.
In the case of weak validation an ETag would look like:
Why is Nginx stripping weak ETag validators in its gzip filter?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx