httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Zumbiehl <>
Subject Re: mod_deflate Vary header
Date Fri, 04 Nov 2005 06:36:52 GMT

> Yes, that is the point. The Vary header describes which header(s) was used
> to decide, which content actually would be delivered. That's what HTTP
> specifies.

To be exact, I'd say that HTTP specifies that it's about representation and
not about content - which might even be the point here: The content
stays the same, just the representation could change, but only in so far
as the client certainly will be able to understand it.

> > When the bottleneck is at the client's end, it's completely different,
> > of course--which is why I'd consider a config option a good idea that
> > would allow the sending of a Vary: Content-Encoding in case of
> > uncompressed content to be disabled.
> For your scenario it would be more useful to adjust the local cache,
> I think. (e.g. always request compressed content, decompress it and
> deliver it to all the clients uncompressed).

Sure - just that you usually don't have any admin access to the vast
majority of the caches that might be accessing the web page you are
publishing =:-)

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

Cya, Florian

View raw message