Accept-Encoding: gzip and the Vary header

Xavier Noria fxn at hashref.com
Thu Jun 4 07:16:45 UTC 2015


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.

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?

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?

Thanks!

Xavier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150604/cfeb1c5c/attachment.html>


More information about the nginx mailing list