httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Sysoev>
Subject Re: mod_deflate Vary header
Date Tue, 08 Nov 2005 06:35:38 GMT
On Fri, 4 Nov 2005 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

View raw message