[Mod_gzip] "mod_gzip_send_vary=Yes" disables caching on IE? (1.3.26.1a)

[mod_gzip@lists.over.net]

In a message dated 12/6/2002 6:40:43 PM Central Standard Time, 
jr-list-mod_gzip@quo.to writes:

> The only reason mod_gzip is sending Vary headers in the first place is to
> prevent Squid from sending back compressed pages to clients that can't
> handle it, right?

Exactly right. 

( Remember this one simple point as this discussion heats up
as I believe it will because the SQUID folks are watching this
discussion very carefully... and for good reason. )

> With my proposed change, mod_gzip would still be sending Vary headers when
> sending compressed data. So Squid should still "know"  not to send the
> compressed pages to clients that can't handle them. (Correct me if I'm
> wrong.)

Ok... you are wrong.

You are giving SQUID ( and any proxy cache ) too much
credit. Caching Servers do what they are told. That's it.

Unless you TELL a caching server that there is some OTHER
special condition other than time/date/expires governing a
cached entity then it is simply going to look at those 
arcane items to decide if it can server up what it has
when it gets an 'If-Modified-Since' request or a brand new 
request from a new user-agent.

The whole idea of "Vary:" was just a hack to get around 
the chance that there might be some reason OTHER 
than time/date/expires to consider when dishing up
a file sitting on a proxy server.

I believe you are also thinking that your average Proxy
cache is somehow able to automatically store 2 different
encoded versions of the same response to the same
request ( compressed and non-compressed ).

There are VERY few Proxy caches that can do this.
It involves parts of the HTTP standards that even the
Proxy Server boys are only now just getting around
to like "Etag:" and stuff like that.

In your scenario... the moment someone forces SQUID
to store a NON-COMPRESSED version of a page
and it does NOT have a 'Vary:' header on it then
everyone who wants the same page after that who
CAN handle compressed data is going to suffer and
NOT get what they should.

Once the Non-compressed response arrives in SQUID
from the Origin Server WITHOUT a "Vary:" header then
SQUID is too stupid to know that it might be simply
only one of a multiple of ENCODINGS that exist for
that particular request.

I believe you are imagining in your mind that SQUID 
( or some other Proxy Cache ) somehow KNOWS
that a compressed response is 'different' froma
non-compressed one. 

SQUID has NO IDEA about that.

Perhaps it should... but that's a whole 'nother story.

I believe what we about to talk about here is that
there CAN and there SHOULD be a 'difference' between
responses that can "Vary:" because of header based
values and responses that should 'automatically' vary
based on the encoding capabilities of the sender/receiver.

It all depends on how 'smart' you think your average
Server OUGHT to be versus not violating the
"principle of least astonishment".

Personally... I am ASTONISHED that any Proxy Server
would ever send a cached response to a user-agent
that doesn't send the correct "Accept-Encoding" to
match what the Proxy has stored... but that's just me.

Yours...
Kevin