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

This smart rule leads us to use just Vary: * on Apache always (for other
still undiscovered bugs in other still undeveloped User-Agents). Squid will
save a ton of disk-space...

Is this what we all wish to have?

Thanks,
Slava

----- Original Message -----
From: "Henrik Nordström" <hno@marasystems.com>
To: <Michael.Schroepl@telekurs.de>
Cc: <sbizyaye@outlook.net>; <mod_gzip@lists.over.net>;
<robertc@squid-cache.org>; <squid-dev@squid-cache.org>
Sent: Tuesday, August 27, 2002 7:18 PM
Subject: Re: Antwort: Re: Antwort: Re: Antwort: [Mod_gzip] Vary: header and
mod_gzip

> On Wed, 28 Aug 2002 Michael.Schroepl@telekurs.de wrote:
>
> > All that counts about M$IE is whether it _tried_ to
> > speak HTTP/1.1 - not whether it really _did_ speak
> > HTTP/1.1. I don't understand why Micro$oft implemented
> > it this way, but this is how it works.
>
> Great! At least they did something correct.
>
> > > I'm accomplishing the response with Vary: Content-Encoding,
> > > and Squid caches it successfully.
> >
> > Which will not happen for all Squids until 2.4, if I
> > understand the current behaviour correctly.
>
> Correction: Squid-2.5.
>
> > > 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.
>
> > 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).
>
> > Netscape 4 will thus get the compressed content and will
> > fail to handle it correctly.
>
> Only if your server failed to emit a correct Vary header, telling Squid
> what your desisions was based upon.
>
> > I am not quite sure whether I should suggest Squid to do
> > the same, because in mod_gzip you have several options:
> > a) you may exclude Netscape 4 OR
>
> Which should be reflected in the Vary header by the inclusion of
> User-agent.
>
> > b) you may exclude JavaScript files.
>
> Which is nothing Squid or other caches needs to care about. If your server
> selects not to apply mod_gzip to certain files then it is only a business
> of your server and it should act as if mod_gzip wasn't there for these
> URLs. Squid does not need to know about it as your server is always doing
> the same thing on all requests for these files.
>
> > 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.
>
> 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.
>
> Note: URLs where mod_gzip would never apply should obviously not have a
> Vary reply headers. Only URLs where mod_gzip might apply should.
>
> Regards
> Henrik
>
>
Received on Tue Aug 27 2002 - 18:33:42 MDT