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

Robert Collins wrote:

> You should not need the Cache-Control: Private directive. The Vary
> directive will 'fix' the data integrity issue for all squid 2.4+ users

Correction: All Squid-2.X users. Detection of the precense of a Vary header
was added during Squid-1.2 beta (what became Squid-2.0), something like 4+
years ago.

> > 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

Correct.

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.

If mod_gzip does additional desisions within the limits set by the HTTP
headers then it is generally fine from a caching perspective if mod_gzip sets
the Vary headers based on the HTTP headers used. This way the user might
sometimes get another format than intended by your server driven ruleset, but
it will atleast be within the parameters acceptable to his browser.

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).

> I.e. content-coding compression within squid? There are *serious*
> architecture issues in squid that we are *currently* resolving that
> would make this quite feasible. I've also implemented Transfer-Encoding
> with on-the-fly-gzip support for squid in the past, but those same
> architectural issues made it unable to be production-quality. I'd be
> interested in your idea all the same - as we get these architecture
> issues out of the way, things should be *much* more feasible.

Transfer-encoding is a slightly different question. Entirely different rules
apply as Transfer-encoding is a hop-by-hop property, not a property of the
object entity like content-encoding is. Transfer-encoding is purely a
business between Squid and the HTTP server (or peer cache) or between Squid
and the requesting client. In that sense Transfer-encoding is a safer
playfield than Content-encoding..

> To summarize what I've learnt about this:
> * There is a extant patch from the openBSD folk, and indeed from the
> early mod_gzip versions, to generate a Vary: header.
> * The author doesn't want to include this at the moment - until Vary
> caching proxies exist.

Which is a chicken-and-egg problem.. Well supported Vary caching proxies is
not likely to exists until there is a demand for correct caching of Vary
objects. Luckily we had a sponsor needing this in Squid for another
application in some senses similar to mod_gzip (different image encodings).

> * It's causing ?numerous? incidents on the mod_gzip list where users are
> complaining about the effects of the missing Vary: header.
> * It's causing occasional reports on the squid lists (growing in
> frequency).

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.

> What I'd love to see is mod_gzip to be distributed with Vary: header
> support enabled, and (optionally) provide a clearly labelled (*this will
> cause X, Y, and Z problems) option to disable Vary support.

I fully support this, as expressed earlier.

> If that causes all the old commercial implementations of HTTP/1.0 to
> stop caching everything... well so what :}? They should support their
> paying customers...

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..

Regards
Henrik
Received on Mon Aug 26 2002 - 08:59:20 MDT