httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Malo ...@perlig.de>
Subject Re: mod_deflate Vary header
Date Thu, 03 Nov 2005 13:37:30 GMT
* Florian Zumbiehl <florz@gmx.de> wrote:

> While configuring and testing my new and shiny Apache 2, I noticed that
> mod_deflate sends a Vary: Content-Encoding header whenever a resource
> could potentially be compressed, no matter whether it actually is
> compressed in that particular response. That certainly should
> work, but in situations where the server's bandwidth is the bottleneck,
> wouldn't it be a good idea to omit that Vary: header when no compression
> actually takes place? After all, any user agent should be able to cope
> with uncompressed content - and when that is what is already "behind
> the bottleneck", like in some local proxy cache, a Vary: Content-Encoding
> header on it would cause a request from a user agent supporting
> compression to cause a reload of the compressed version from the slow
> server rather than delivering the already locally-available uncompressed
> version.

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.

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

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.

nd

Mime
View raw message