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

Hi Henryk,

>> > Unfortunately, the structure of mod_gzip doesn't allow for this,
>> > as it is doing negotiation on things that are _not_ part of the
>> > HTTP header, so it seems to be impossible to express in the
>> > "Vary:" header what mod_gzip _really_ did.
>> Hmm? If it looks at 2 headers - say Accept-Encoding: and User-Agent:,
>> then the Vary: header should be
>> Vary: Accept-Encoding User-Agent

But mod_gzip is doing the decisions process based on informations
that Squid cannot ever have a clue about.
Several of these are no HTTP headers at all, but Apache internal
informations, or they are HTTP response headers, not request
headers (Content-Length, Content-Type, ...).

> In case the precense of a Accept-Encoding in some cases is sufficient
> (User-Agent then ignored) then the header may in such cases contain
> just "Vary: Accept-Encoding", but Squid will be happier if the Vary
> header is consistent on all replies as Squid-2.5 is only capable of
> maitaining one Vary "type" per URL.

mod_gzip will only serve one of two possible formats: compressed
and uncompressed.
Data will never be compressed if the client didn't send "Accept-
Encoding: gzip"; but there may be _many_ cases when the client
asks for compressed data and will still get uncompressed content.

Am I right to think that "Vary: Accept-Encoding" for the compres-
sed content and no "Vary:" header at all will be the best choice
in this case? This is what the two published patches are doing.

> Alternatively you can use "Vary: *" to tell caches that there is
> parameters outside HTTP being used, but then there will always be
> a roundtrip to the origin HTTP server to decide which of the variants
> to return to the user via If-None-Match (not before Squid-2.6).

This is the reason why there should be a discussion which Squid
version would like which mod_gzip/Apache behaviour most.
_If_ Squid would always send a "Via" or "X-Forwarded-By" header
or whatever so that mod_gzip would be able to understand which
proxy server it is dealing with, then it would be able to decide
whether to serve compressed content based on this information.

There have been examples in the past where "mod_gzip_item_exclude
reqheader" has been used to detect proxy servers that are known
to unconditionally store compressed content ...

> Which in all cases so far results in the Squid user adding the whole
> site to a cache blacklist, denying caching of the whole site.

Or resulting in the mod_gzip configuration adding the proxy to a
non-compression blacklist, denying compressing for all requests
coming from this direction - if the proxy tells who it is.

> Agreed. And even then, their customers are less likely to complain
> than if the cache returned "wrong" data making it impossible for
> some of their users to access the content. From speaking with a
> couple of commercial cache wendors over the years I know many of
> them maintain large blacklists of HTTP servers not sending correct
> information to caches, and I would not be surpriced if mod_gzip is
> on several of those blacklists by now, possibly entirely denying
> caching of objects (or at a minimum any gzipped objects) from servers
> advertising mod_gzip capabilities..

Another possibility that I experienced myself: A proxy that is
filtering out "Accept-Encoding" headers from forwarded requests,
as to be sure it may cache each and every response.
This one even must be a Squid 2.4, if I read my HTTP header
traces correctly ...

Greetings, Michael
Received on Mon Aug 26 2002 - 13:12:52 MDT