Hi
> On 4 Jun 2015, at 08:16, Xavier Noria <[email protected]> wrote:
>
> 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 representation", and my understanding is that
> compressed content is not a representation per se. The representation would
> be the result of undoing what Content-Encoding says.
This is fine to do. However, there's a chance a proxy may cache an uncompressed
version if a client does not support compression and its response ends up in a
proxy cache. Any subsequent user also behind that cache, even if it accepts
compression, would be served it uncompressed in most cases.
> So, given the same .html endpoint you could for example serve content in a
> language chosen according to Accept-Language. That's a representation that
> depends on headers in my understanding. If you serve the same .css over and
> over again no matter what, the representation does not vary. The compressed
> thing that is transferred is not the representation itself, so no Vary needed.
>
> Do you guys agree with that reading of the spec?
This bit of the spec (same page at bottom) explains it better I think:
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
agent about the presence of negotiation on that resource.
I would say compression is a server driven negotiation. I would also say, based
on my understanding, that when the spec says representation it means including
encoding such as compression. That is, you can represent a resource with gzip
or without gzip.
> Then, you read posts about buggy proxy servers. Have any of you founded a
> real (modern) case in which the lack of "Vary: Accept-Encoding" resulted in
> compressed content being delivered to a client that didn't support it? Or are
> those proxies mythical criatures as of today?
Proxy are bound by the spec too so yes it would be a buggy proxy. They can't
send a Content-Encoding gzip unless the client sends Accept-Encoding. I'm not
entirely sure what would happen though - I guess either bypass the compressed
cache version or replace it uncompressed. Most likely up to the proxy
implementation.
Jason
_______________________________________________
nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx
