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:18:47 MDT