[squid-users] Vary / Accept-Encoding / mod_gzip Redux

From: R Pickett <emerson@dont-contact.us>
Date: Wed, 7 May 2003 13:14:00 -0700 (PDT)

Howdy. I've spent several hours over the past three days reading over the very
enlightening thread from last August in the dev list archive about mod_gzip and
squid learning to play nice. Since then, both pieces of that equation have
changed in the direction of proper Vary and Accept-Encoding support,
significantly, but I'm still seeing undesirable results, and wanting to ask
Smarter Folks(tm) if there's some simple fix I'm overlooking.

For the most part, the whole "Vary: Accept-Encoding" scheme is working
perfectly with squid caching mod_gzip content. The issue comes when a browser
doesn't send an Accept-Encoding header, as is the case both for MSIE and Safari
on OS X, at the very least. In this situation, squid will send back the
gzip-encoded content (if it's in the cache -- if we go back to the origin
server, the right thing happens), which neither of the above mentioned browsers
can handle.

In the August thread, it was pointed out that the RFC specifically states that
a lack of an Accept-Encoding header means that the server may assume the
browser can accept any content encoding, so squid (playing the role of the
'server' in this drama) is being RFC-compliant, but is still sending incorrect
content.

Is there a simple fix to make squid serve up 'identity' content if it gets a
request with no Accept-Encoding header? Or some other hack that will have the
same effect?

Thanks in advance for any thoughts y'all have on this.

--
R Pickett <emerson@craigslist.org>
craigslist.org
Received on Wed May 07 2003 - 14:14:34 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:16:21 MST