fre 2008-04-11 klockan 12:43 -0400 skrev Chris Woodfield: > Further poking suggests that this is due to how the object is > delivered when it is first loaded into the cache. For example, when I > purge the object from the server that is not delivering the object > gzip'ed, then request it, the miss results in the object being gzip'ed > on deliver. Worse, when I remove the "Accept-Encoding: gzip" header > from subsequent requests, I still get the gzip'ed object. This depends on if the server sends a proper Vary header or not, and if the server properly handles ETag. Squid doesn't gzip content on it's own. That's done by the origin server in response to requests from clients capable of decoding gzip:ed content. Squid just caches the result, and for that cache to work proper the instructions from the origin server on when the gzip:ed variant is valid needs to be correct. - The response needs to indicate "Vary: Accept-Encoding", telling caches that the response varies based on the contents of Accept-Encoding request header. - If there is a ETag in the response then the plain and the gzip:ed variants need to have different values for ETag. They MUST NOT have the same value. But as this is a common bug you can teach Squid to work around this by using the broken_vary_encoding directive. There is no workaround for a missing/incorrect Vary response header however. > Is this due to incomplete gzip support in squid 2.6? I'm guessing > what's happening here is that squid is ignoring the header and passing > it along verbatim to the origin, which delivers gzip'ed content. What > is the current state for gzip support in 2.7 or 3.0? The same as 2.6. It's the origin server that compresses, not Squid. This is by design in HTTP. Regards Henrik
