httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: mod_deflate Vary header
Date Tue, 08 Nov 2005 03:53:47 GMT

> Igor Sysoev wrote
> Actually, with MSIE 5.5+ appearance the chances that client can not
> decompress the response from downstream cache have increased.
> If MSIE 5.5 is configured to work via proxy with HTTP/1.0, then
> MSIE will never send "Accept-Encoding" header, and it would refuse
> the compressed content.

You are right on the first part. If you don't have the "Use HTTP/1.1
for Proxies" checkbox on then no "Accept-Encoding:" header
would be sent... ( principle of least astonishment applies here ).

...however... I think you will discover on closer inspection that
the second part is not true. Even if MSIE 5.x doesn't send an
"Accept-Encoding: gzip" header... it KNOWS it can decompress
and will do so for any response that shows up with "Content-encoding: gzip"
regardless of whether it sent an "Accept-Encoding: gzip" header.

It's part of the wild and whacky world of browsers. Netscape exhibits
similar behavior. Rather than rejecting something when they know
they can do it, regardless of protocol 'envelope'... they just go ahead 
and do it anyway.

There were ( are ) versions of Netscape, MSIE and Opera that were
capable of decompressing "Content-encoding: gzip" even BEFORE
they added any HTTP/1.1 support at all. 

Go figure.

> Actually, MSIE 5.5+ will cache the response with any "Vary" header
> if it also has "Content-Encoding: gzip" or "Content-Encoding: deflate"
> headers. But it refuses to cache if the response has no
> "Content-Encoding: gzip" header.

Thanks for pointing that out. You are right. I didn't make that
exception clear in last message.

If response has "Content-Encoding: gzip ( or deflate )" then
It HAS to cache it. It will even do so beyond all "Cache-Control:"

Both MSIE and Netscape actually USE their own
local cache to perform the actual decompression and,
as such, will ALWAYS write the compressed data to 
disk first regardless of any "Cache-Control:" directives
or "Vary:" headers or anything else, for that matter.

MSIE will end up with only the decompressed version 
in the cache but Netscape will end up with TWO copies of 
the response in  it's local cache... the original compressed 
version and the decompressed version. 

Only problem with Netscape is that
it then goes brain-dead and forgets that it has 2 cached
copies of the same response and sometimes tries to actually
PRINT the compressed version of the response out of
it's local cache. Not sure they ever solved that one.

"Vary:" really doesn't hold much meaning for end-point
client caches, anyway, so it's curious that it actually affects
browser caching behavior one way or the other. "Vary:" is/was 
mostly meant to just help intermediate caches figure out "what to send"
to actual end-point agents ( the ones ASKING for the right response ).

I can't think of many HTTP response headers that would/should matter 
a hoot to the end-point browser as far as "Vary:" goes once it has 
a response to a request. It's all about 'freshness' from the end-point
cache's point of view. It's the browser that expects someone else to
"Vary:" the response based on the REQUEST headers it sent.

Only reason I ever heard for MSIE deciding to never cache any
response with a "Vary:" header ( Other than compressed responses )
goes back to some huge bug they had to fix that was being caused
by a "Vary:" header and, rather than actually add true "Vary:" support,
the quick fix was to just reject everything. Better to point the blame
upstream than ( God forbid ) show the user the wrong thing.

I believe Netscape used the same approach. If you can't do ALL
of the "Vary:" rules then safest thing to do is just reject it all
and let someone ( or something ) else worry about getting you
the right content. 

This was also SQUID's philosophy with regards to "Vary:"
in the not-too-distant past, before they made any attempt
to support multiple variants at all.

SQUID would never bother to cache ANYTHING that had
a "Vary:" header on it.

> My mod_deflate allows optionally to add "Vary" header to compressed
> response only.

So you still run the risk of only getting one variant 'stuck' in a
downstream cache. If the uncompressed version goes out at
'start of day' with no "Vary:" then the uncompressed version
can get 'stuck' where you don't want it until it actually expires.

Kevin Kiley

View raw message