On ETag removal by the gzip module.

Albert Casademont Filella albertcasademont at gmail.com
Mon Oct 6 15:56:09 UTC 2014

Hi Manuel,

The weak etag preservation was added to nginx 1.7.3 so I guess your problem
is that you're still on the 1.6.* branch! Hope that helps :)


On Mon, Oct 6, 2014 at 4:34 PM, Manuel Vázquez <manuel at merchise.org> wrote:

> 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.
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20141006/4a68a729/attachment.html>

More information about the nginx-devel mailing list