Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: domain of florz@gmx.de designates
 213.165.64.20 as permitted sender)
Date: Fri, 4 Nov 2005 07:36:52 +0100
From: Florian Zumbiehl <florz@gmx.de>
To: dev@httpd.apache.org
Subject: Re: mod_deflate Vary header
Message-ID: <20051104063652.GA2942@florz.florz.dyndns.org>
References: <20051103120821.GF2423@florz.florz.dyndns.org>
 <20051103143730.00006516@fe-pc-323.webde.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20051103143730.00006516@fe-pc-323.webde.local>
User-Agent: Mutt/1.5.9i

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