MSIE 6.0; Windows NT 5.0)"
HTTP/1.1 200 OK
Server: nginx/1.1.14
Date: Fri, 02 Mar 2012 07:04:25 GMT
Content-Type: text/xml; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Pingback: http://animebsd.net/xmlrpc.php
Last-Modified: Fri, 02 Mar 2012 04:17:00 GMT
ETag: “92a5989a0949b85e303228490256ebf2”
X-Powered-By: W3 Total Cache/0.9.2.4
Link: http://wp.me/Pig2n-5B; rel=shortlink
I don’t think this is intentional as getting non-gzipped content
doesn’t return such header. (I’ve verified this is returned by nginx
by running same test with disabled gzip_vary)
(I don’t see mention of this being fixed in .15 and .16 in the
changelog so I haven’t tested with them)
I don’t think this is intentional as getting non-gzipped content
doesn’t return such header. (I’ve verified this is returned by nginx
by running same test with disabled gzip_vary)
This is intentional, “Vary” is returned whenever gzip (and
gzip_vary) is enabled, as response representation depends on
header(s) listed.
Strictly speaking, it should also include User-Agent in case of
gzip_disable defined.
So, the “gzip enabled response” includes cases with non-gzip content as:
no “Accept-Encoding: gzip,deflate”
matches gzip_disabled
and therefore “Vary: Accept-Encoding” will always be added even though
the response isn’t compressed?
Or in other words, does “gzip on; gzip_vary on” means “add ‘Vary:
Accept-Encoding’ header on any responses matching gzip_types
regardless whether the response actually compressed or not”?