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.pl...@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/
