Weak ETags and on-the-fly gzipping

[Maxim Dounin]

Hello!

On Sat, Jun 15, 2013 at 02:58:33PM +0200, Matthijs Langenberg wrote:

> 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?

Just stripping ETags are easier than converting them to weak 
etags (and implementing weak etags support various places).

On the other hand, relevant caching functionality is still here 
with Last-Modified cache validator.

-- 
Maxim Dounin
http://nginx.org/en/donation.html