On ETag removal by the gzip module.

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 :)

Albert

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>