<div dir="ltr">I have used gzip_static for some years without any issue that I am aware of with the default gzip_vary off.<div><br></div><div>My reasoning is that the HTTP spec says in</div><div><br></div><div>    <a href="http://tools.ietf.org/html/rfc2616#page-145">http://tools.ietf.org/html/rfc2616#page-145</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Do you guys agree with that reading of the spec?</div><div><br></div><div>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?</div><div><br></div><div>Thanks!</div><div><br></div><div>Xavier</div><div><br></div></div>