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

[Slava Bizyayev]

On Sun, 8 Dec 2002 TOKILEY@aol.com wrote:

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

Agree.

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

Except "Vary: *" which is absolutely legal and is not associated with any
request header. It is defined by rfc2616 especially to serve some
special responses, like personalized content.

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

Agree. That's why we have to guess so often about those products...

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

Disagree. When for example you provide the User-Agent specific JavaScript,
or CSS, you would consider to place "Vary: User-Agent" in your response even with no
compression at all.
It is not supposed to affect the Expires header which you could provide with the same response.

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

It is conflicting with
http://www.schroepl.net/projekte/mod_gzip/browser.htm - Michael Schroepl's
Site. I didn't check it carefully, but I recall a bunch of problems with
M$IE, related to incorrect headers I generated on the beginning stage of
Apache::Dynagzip...

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

Last time I've sent my request to M$ on June 13, 2002. I'm still waiting
for the response...

Thanks,
Slava