* Florian Zumbiehl <[EMAIL PROTECTED]> 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
