httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Plüm, Rüdiger, VF-Group" <ruediger.pl...@vodafone.com>
Subject RE: canned deflate conf in manual -- time to drop the NS4/vary?
Date Fri, 04 Jun 2010 13:10:32 GMT
 

> -----Original Message-----
> From: Brian Pane [mailto:brianpane@gmail.com] 
> Sent: Freitag, 4. Juni 2010 14:39
> To: dev@httpd.apache.org
> Subject: Re: canned deflate conf in manual -- time to drop 
> the NS4/vary?
> 
> On Fri, Jun 4, 2010 at 2:18 AM, Mark Nottingham <mnot@mnot.net> wrote:
> [...]
> > It's not a bug in the implementations, it's a grey area in 
> 2616 that HTTPbis has since worked to resolve;
> >  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147
> 
> By my reading of the attachments in that ticket, servers 
> (including caches)
> would be required to treat the following as equivalent to each other:
>     Accept-Encoding: gzip, deflate
>     Accept-Encoding: gzip,deflate
>     Accept-Encoding: deflate, gzip
>     Accept-Encoding: deflate,gzip
> and the following as different from each other:
>     Accept-Encoding: gzip,deflate
>     Accept-Encoding: gzip
> 
> If so, the RFC 2616 patch would basically codify current good
> practices in cache configuration (I recall that the Varnish docs, for
> example, recommend normalizing the Accept-Encoding before using it in
> a cache key), and as such it would be a step forward.
> 
> In practice, given a cache that implements these equivalence rules and
> an origin server that sets a Vary header on Content-Encoding, I'd
> expect the cache to end up holding up to three copies of each object:
> 1. compressed, with a cache key of something like URI+"gzip,deflate"
> 2. compressed, with a cache key of URI+"gzip"
> 3. uncompressed, with a cache key of URI+""
> 
> That's fewer copies of the object that the cache would end up with if
> it did a strict text match on the different permutations of
> "gzip,deflate"; but it's still a lot of copies.
> 
> So I have to ask: why not reduce the number of copies to just one, by
> turning Content-Encoding into a hop-by-hop header and deprecating the

Isn't that what Transfer-Encoding is designed for?

Regards

Rüdiger


Mime
View raw message