On ETag removal by the gzip module.

[Manuel Vázquez]

Hi all,

I'm not a nginx developer; just an user.

Recently I deployed OpenERP and use nginx as a front end, mainly to:

1. Deal with slow clients
2. Add gziping support to our app.

Some context:

Many of the application users access it using a modem connection (up to 
56kbps).  So both caching and gzipping are key to performance.

OpenERP builds a single CSS and a single JS from installed modules' 
sources.  And creates a strong Etag for both responses, and uses a 
"Cache-Control: must-revalidate, max-age=0"

But then nginx removes the Etag and caching is hindered.

I've read the following thread (from several months ago): 
http://mailman.nginx.org/pipermail/nginx-devel/2013-November/004498.html

There are several things I don't fully understand:

Compression is a means to improve performance, not to change semantics 
of the content.  I don't see why compression would affect the entity's 
content/semantic.  Both browsers and caches should store the content as 
if compression would not have been applied, or apply a disk-saving 
compression themselves, but that would be out of HTTP reach.  Am I 
right?  Or more precisely where am I wrong?

Though I have read the RFC, I hardly consider myself an expert on it...

In order to avoid the Etag removal I'm using just compressing the AJAX 
responses (application/json).  But up-front then the up-front 1.5MB JS 
file won't be compressed and clients may have to wait longer than needed.

After reading the thread above I changed the Etag to be a weak one, but 
it still gets removed.  Do I need to do anything else?

Summary:

Why does gzipping interferes with etaging?


Best regards,
Manuel.