On Fri, 4 Nov 2005 [EMAIL PROTECTED] wrote:
This has been discussed many times before and no one
seems to understand what the fundamental problem is.
It is not with the servers at all, it is with the CLIENTS.
What both of you are saying is true... whether you "Vary:"
on "Content-encoding" and/or "User-agent" or not... there
is a risk of getting the wrong content ( compressed versus
uncompressed ) "stuck" in a downstream cache.
It is less and less likely these days that the cache will receive
a request from a client that CANNOT "decompress", but still
possible. Handling requests from clients that cannot decompress
have become ( at long last ) the "fringe" cases but are
no less important than ever.
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.
This is why my mod_deflate for Apache 1.3 by default does not compress
response for proxied requests.
Microsoft Internet Explorer ( all versions ) will REFUSE to cache
anything locally if it shows up with any "Vary:" headers on it.
Period. End of sentence.
So you might think you are doing your downstream clients a
favor by tacking on a "Vary:" header to the compressed data
so it gets 'stored' somewhere close to them... but you would
be wrong.
If you don't put a "Vary:" header on it... MSIE will, in fact,
cache the compressed response locally and life is good.
The user won't even come back for it until it's expired on
their own hard drive or they clear their browser cache.
However... if you simply add a "Vary:" header to the same
compressed response... MSIE now refuses to cache that
response at all and now you create a "thundering herd"
scenario whereby the page is never local to the user for
any length of time and each "forward" or "back" button
hit causes the client to go upstream for the page each
and every time. Even if there is a cache nearby you would
discover that the clients are nailing it each and every time
for the same page just because it has a "Vary:" header on it.
I believe Netscape has the same problem(s).
I don't use Netscape anymore.
Anyone know for sure if Netscape actually stores "variants"
correctly in local browser cache?
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.
My mod_deflate allows optionally to add "Vary" header to compressed
response only.
Igor Sysoev
http://sysoev.ru/en/
