Weak ETags and on-the-fly gzipping

[Matthijs Langenberg]

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
compression.

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:
ETag: W/"123456789"

Why is Nginx stripping weak ETag validators in its gzip filter?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130615/87da2d1d/attachment.html>