httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Nottingham <m...@mnot.net>
Subject Re: canned deflate conf in manual -- time to drop the NS4/vary?
Date Sat, 05 Jun 2010 02:13:39 GMT
Changing the semantics of Accept-Encoding / Content-Encoding is likely out of scope for HTTPbis;
I have a hard time believing it wouldn't make existing implementations non-conformant, which
we can really only do if there's a serious security or interoperability concern.

OTOH I think it would be reasonably easy to change Squid and other intermediaries to "pass
through" TE; i.e., if the client asks for hop-by-hop compression, ask the server for hop-by-hop
compression as well (so they don't have to dynamically decompress and possibly buffer responses
for clients that don't support it). 

The question would be whether any reasonable number of browsers would start sending TE. Given
that both Chrome and FF are on a perf kick these days, I think it's possible. The problem
with hop-by-hop compression has always been that "no-one else does it"... if Apache were to
start, that would be a step.

Interestingly, it appears that Mozilla had partial support at one time:
  http://www-archive.mozilla.org/projects/apache/gzip/

> Here we hope to use the new HTTP1.1 TE: gzip header to request compressed versions of
HTML files. Then the server would need to do streaming compression to generate the results.
To minimize the overhead on the server it should keep a cache of the compressed files to quickly
fill future requests for the same compressed data.
> 
> The current Mozilla source can already accept and decode Transfer-encoding: gzip data,
but does not currently send the TE: header.

but I can't find the corresponding code in the current Mozilla source.

Regards,


On 04/06/2010, at 11:36 PM, Brian Pane wrote:

> On Fri, Jun 4, 2010 at 6:10 AM, "Plüm, Rüdiger, VF-Group"
> <ruediger.pluem@vodafone.com> wrote:
> [...]
>> Isn't that what Transfer-Encoding is designed for?
> 
> Yes, and in fact if we were talking about a brand new protocol, I'd
> probably argue in favor of putting the compression specifier in the
> Transfer-Encoding.  I think a change in the semantics of
> Content-Encoding in HTTP/1.1 might be a way to obtain similar benefits
> without breaking existing software.
> 
> -Brian


--
Mark Nottingham     http://www.mnot.net/


Mime
View raw message