On Thu, Jun 4, 2015 at 9:36 PM, Xavier Noria wrote:
gzip_proxied on;
>
s/on/any/
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Ahhh, I see.
We've seen that if you want cache + compression, then you need Vary. So
by counter-reciprocal the trade-off of gzip_vary off is that the response
can't be cached at all in the sense that you're not sending the proper
headers. *No matter if the cache is private or shared*. At least in
On Thu, Jun 4, 2015 at 3:11 PM, Maxim Dounin wrote:
The problem with Vary is that it causes bad effects on shared caches, in
> particular, it normaly results in cache duplication.
You mean that if client A requests a resource with Accept-Encoding: gzip,
and client B without, and the resource ha
On Thu, Jun 4, 2015 at 10:56 AM, Jason Woods wrote:
An HTTP/1.1 server SHOULD include a Vary header field with any
>cacheable response that is subject to server-driven negotiation.
>Doing so allows a cache to properly interpret future requests on that
>resource and informs the user ag
I have used gzip_static for some years without any issue that I am aware of
with the default gzip_vary off.
My reasoning is that the HTTP spec says in
http://tools.ietf.org/html/rfc2616#page-145
that "the Vary field value advises the user agent about the criteria that
were used to select the
