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.
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?
Yours...
Kevin Kiley
In a message dated 11/4/2005 4:55:02 PM Central Standard Time, [EMAIL PROTECTED] writes:
On 11/04/2005 07:36 AM, Florian Zumbiehl wrote:
[..cut..]
>
>>Maybe I'm pessimistic, but I think, omitting the Vary header for
>>uncompressed ressources will lead to "poisoned" caches, which statistically
>>nearly always will request the uncompressed variant and so actually
>>*add* load to your server's bandwidth.
>
>
> Hu? Erm, could it be that you are thinking of load-reducing caches put
> directly in front of the web server? In that case, I wonder how the web
> server's bandwidth could be the bottleneck?!
>
> To put this straight: I was thinking about web servers behind
> V.90/ISDN/ADSL lines where _that_ line usually will be the bottleneck
> on any connections to the outside world and about caching proxies
> in that outside world ...
Yes, but if you do compression because some of your clients have low bandwith
connections (but are capable of receiving compressed pages) and access your
server via a proxy then not sending the Vary header can "poison" the cache in a way
you do not want. Because if the client which causes the proxy to cache the response
is not capable to receive compressed pages will cause the proxy to cache *only* the
uncompressed version of the page.
Regards
Rüdiger
