Antwort: Re: Antwort: Re: Antwort: Re: Antwort: [Mod_gzip] Vary: header and mod_gzip

Hi Henryk,

>> > 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?
>> Yes, _this_ is a problem.
> If your server has a rule that excludes NN-4.X then your
> server should respond with a Vary: header that includes
> the User-agent header to prevent this from happening.

Agreed. Just as I wrote in some other mail: mod_gzip
would have to parse its rule set, detect all
     mod_gzip_item_**clude reqheader
rules and collect the HTTP header names from them.

>> Squid doesn't know that Netscape is a liar (that cannot
>> handle compressed JavaScript files), and has to trust
>> the "Accept-Encoding" header it will send.
> What Squid trusts is the Vary header sent by your server.
> Squid is (and should be) completely ignorant on what
> Accept-Encoding is (it just another plain HTTP request
> header).

This may be HTTP/1.1 confirming, but it is really a pity.

If Squid 2.4 _did_ treat Accept-Encoding as something
special, it would be able to prevent M$IE running in
HTTP/1.0 from unexpectedly receiving gzipped content,
thus "questioning" the "obviously" missing "Vary:"
header.
(If encoded content is there, it _should_ at least de-
pend on the "Accept-Encoding" header - Squid could be
suspicious about this combination and rather not use
the cache content in this case, but "punish the server"
by forwarding the request. Isn't this an option?)

Of course this would not help in the Netscape 4 issue,
but the M$IE issue seems to be ten times as important,
given the current market shares of both.

>> Given a scenario where no proxies exist, this flexibility
>> is the great strength of mod_gzip. Given a scenario where
>> mod_gzip needs to tell what it did to other HTTP partners,
>> this may well be a problem as we see right now.
> It might not be as big problem as it first seems. The rules
> is pretty simple: If the HTTP server uses rules on HTTP
> headers for this specific URL then all these headers should
> be listed in the response Vary header.
> Does not matter if the rule was a match or not, the header
> should always be included in Vary.

This will likely result in a very long "Vary:" list.
My huge mail earlier was the attempt to detect situa-
tions where none or a very short "Vary:" list could
be provided, to make matching in the proxy as easy
as possible,

> Meaning: If your server is configured for this URL to respond
> with gzipped replies to all "Accept-encoding: gzip" requests
> except for Netscape-4 User-agents then it should respond with
> "Vary: Accept-encoding, User-agent". At a minimum on all
> gzipped replies, but preferably on all.

Even on those where a "mod_gzip_item_exclude uri" rule
will definitely prevent compression? Or in a lot of
other situations mod_gzip _could_ be able to detect,
given an enhanced rules checking mechanism?

> Note: URLs where mod_gzip would never apply should obviously
> not have a Vary reply headers. Only URLs where mod_gzip might
> apply should.

See my veeeery long mail about this topic.

Greetings, Michael
Received on Tue Aug 27 2002 - 21:16:17 MDT