On Mon, 26 Aug 2002, Slava Bizyayev wrote:
> I understand your position Henrik. Just in case...
> I'm just wondering how the chain of browser->Squid->httpd->Squid->browser
> could interfere with some browser's bugs, finally affecting the delivered
> content.
>
> For example, let's say that MSIE is requesting some.js file using
> HTTP/1.1 via Squid. It sends usual Accept-Encoding: gzip, and it really
> can uncompress gzip over HTTP/1.1. But Squid downgrades HTTP/1.1 to
> HTTP/1.0, and httpd sees HTTP/1.0 from MSIE accomplished with
> Accept-Encoding: gzip. We know exactly that MSIE does NOT speak gzip over
> HTTP/1.0. Will it be correct to respond gzip in this case?
If you know MSIE cannot uncompress HTTP/1.0 replies even if requesting
compression by Accept-Encoding then you need to do a number of things
a) As you now include User-Agent into the desision matrix your Vary
header SHOULD mention this "Vary: Accept-Encoding, User-Agent" when
detecting that there might be a HTTP/1.0 proxy in the request path. This
is on all candidate replies, not just replies to requests from broken
browsers.
b) Bash the browser vendor in the head with a cluebat. They SHOULD
accept what they advertise.
c) Have a browser blacklist listing known buggy browsers, and don't
respond with compressed content to those if you for any reason suspect
there might be a HTTP/1.0 proxy in the request chain.
d) Have a FAQ entry that users of such broken browsers must disable the
use of HTTP/1.1 in their browser preferences.
Alternatively cooperate with the HTTP/1.0 proxy wendors and have them
implement a browser version blacklist and automatically remove
"Accept-Encoding: gzip" when detecting such requests from broken browsers.
> I have no clue.
> I did never have a chance to test this particular situation, but it looks
> confusing for implementation of content compression.
True. Such bugs really messes things up for users of such buggy browsers.
The condition to look for to see if there is a HTTP/1.0 proxy in the path
is if the received HTTP version is HTTP/1.0 or if there is any HTTP/1.0
hop in the Via header.
> It's not clear, but just in case, let's imagine that I send back gzipped
> response over HTTP/1.0, and MSIE is lucky to uncompress it correctly.
> I'm accomplishing the response with Vary: Content-Encoding, and Squid caches
> it successfully.
Good.
> The next NN-4.X is coming to Squid to order the same file over HTTP/1.0
> with it's buggy Accept-Encoding: gzip. But Squid does not care about that.
> What the content will be delivered to that poor fellow on NN-4.X?
If you find you need to do such destinctions between browsers, you should
emit a "Vary: Accept-Encoding, User-Agent" header to tell caches what you
based your desision upon. If you do not include User-Agent then the caches
will not know they need to look at the User-Agent header.
As above you can get cooperation from cache vendors with blacklist
capabilities at the proxy to remove the "Accept-Encoding: gzip" header
when buggy browsers is detected that fail due to HTTP/1.0 downgrade, but
by administrative reasons the capabilities most likely need to be at both
ends.
Regards
Henrik
Received on Tue Aug 27 2002 - 01:46:22 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:16:14 MST