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

[mod_gzip@lists.over.net]

> On Sat, 7 Dec 2002, Jordan Russell wrote:
>
>>: But then, as usual, if I add in gzip encoding, IE caches the page just 
fine:
>>:
>>: header("Content-Encoding: gzip");
>>: header("Vary: Content-Encoding");
>>: header("Expires: Mon, 08 Dec 2003 00:00:00 GMT");
>>: echo gzencode("Hi");
>
>What about if you explicitly use:
>
>header("Content-Encoding: identity");
>header("Vary: Content-Encoding");
>header("Expires: Mon, 08 Dec 2003 00:00:00 GMT");
>echo "Hi";
>
>?  See the "identity", uncompressed, encoding.
>
>Note that this is *NOT* the same test that Slava is requesting, as I did not
>put "Vary: *" up there (which is likely to blow away caches anyway).

As Robert ( SQUID developer ) has already pointed out...
...it makes no sense to use a RESPONSE header
like "Content-Encoding" with "Vary:".

"Vary:" is only meant to be used to indicate what REQUEST
headers might be involved in the 'varying' conditions that
might influence what PROXY CACHE should do.

In other words... "Vary:" is IN the RESPONSE headers but
is only supposed to reference REQUEST headers.

Also... keep in mind that browser 'caches' are NOT
actually PROXY CACHES. Sure... any good browser is
going to have a file cache and will be checking the 
'cached' files for time/date/expires to see if they
are 'fresh', locally, but this does not mean that browsers
will behave according to the HTTP/1.1 Proxy Cache "rules".

There is no requirement for them ( the browsers ) to do so
since they are NOT Proxy Servers.

Browsers do all sorts of things with their own local cache
files that are not in any specifications set down anywhere
and this is as it should be. It is the browsers business what
it does with its own ( proprietary ) cache and the files it
chooses to store there.

I still think what you are witnessing in MSIE is simply 
the following...

1. If a response shows up with a "Vary:" header and there
isn't any compressed data along with it... then MSIE 
will NOT cache that response because it has no idea
how to handle "Vary:" ( nor is it really supposed to 
since it's not really a Proxy Cache ). It is simply doing what 
even SQUID has done with regards to "Vary:" up until 
just 7 weeks ago when SQUID 2.5 was released. SQUID 
would just refuse to ever cache anything that had a "Vary:" 
header.

2. The only reason the COMPRESSED responses are
actually being "cached" by MSIE has nothing to do with
any response header at all. MSIE is forced to open a
cache file for compressed responses because it NEEDS
that disk file to perform the decompression.

It has nothing to do with whether the 'Content-Encoding: gzip'
response header is sent or not. There has to ACTUALLY be
'compressed data' arriving.

You really don't even need the "Content-Encoding: gzip"
response header when sending compressed data to MSIE.

Last time I checked... MSIE is always checking for certain
'magic signature' bytes at the start of the body data to 
determine what is REALLY arriving and it will automatically
'sense' an LZ77 compression stream when it starts
arriving regardless of what the "Content-Encoding" field says.

This 'magic signature' check dates back to the time when
lots of bad server software was screwing up the actual
'Content-Type:' response field and it was often WRONG.

If anyone wants to know exactly what MSIE is doing with
regards to "Vary:" then I suggest you just ASK them.

According to the new legal rulings against Microsoft... this
is exactly the kind of thing they are supposed to 'disclose'
if anyone simply 'asks' them what their proprietary code
is actually doing... and the answers are supposed to 
be forthcoming and correct.

Might be a good 'test' of the new law(s).

Yours...
Kevin