Hi, > 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
