OK, understood...it appears that the issue is the origin server
sending the same ETag for both plaintext and gzip'ed content. The
origin server is lighttpd 1.4.18. So now I need to determine if this
is due to inherent brokenness in lighttpd or if it's just a
misconfiguration. Anyone have any insight on this?
Next question: if I set broken_vary_encoding to match on lighttpd (or
if we can fix the server), will squid cache two versions of the file
depending on the encoding, or will a gzip'ed version push a plaintext
version out of the cache and vice versa?
Thanks for the help.
-C
On Apr 11, 2008, at 6:22 PM, Henrik Nordstrom wrote:
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
