On ETag removal by the gzip module.
manuel at merchise.org
Mon Oct 6 14:34:04 UTC 2014
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.
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):
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?
Why does gzipping interferes with etaging?
More information about the nginx-devel