RE: Porting T-E to HTTP/2: Reasons Against

On Friday,11 April 2014 02:19, Matthew Kerwin wrote:

> I still believe there's a significant case that HTTP/2 doesn't address, that HTTP/1.1

> (theoretically) does: allowing compression after entity-specific operations (such as ranges).



We actually need that feature, but finally we accept: HTTP/2 will NOT support it. We proposed 3 options:

1)    Reintroduce "Transfert-Encoding: gzip": We agree that is not an option because it is a hop-to-hop header with all the associated consequences.

2)    Introduce a "Message-Encoding" which is in almost all cases like "Content-Encoding", specifically end-to-end. The significant difference is in the semantics of a range (range is applied after Content-Encoding; while range is applied before Message-Encoding). With Message-Encoding the server can compress a range. Due to the subtle difference we got responses like "...effectively makes it a redundant duplicate of CE" [1].

3)    Independent frame-by-frame compression with a negligible compression ratio "length(compressed data) / length(raw data)" increase. The intention was an end-to-end compression like with "Message-Encoding", but allowing the intermediary the option to directly serve range requests (most likely the first (and last frame) uncompressed) with small memory/CPU footprint.



We believe the original intent of C-E was efficient handling of pre-compressed content. Since C-E was adopted early on by almost all HTTP/1.1 implementations, C-E was also adopted for compressing dynamic content, to speed up a transfer (and despite the misuse causes no problems). For non-pre-compressed static content (likely a bad server design/usage), dynamic C-E requires, at best, useless CPU-processing when serving a range (somehow a range of something which does not exist). We think it is a DoS attack to ask a server for "Range: -1" which requires lots of CPU on the server to compress the entire content just to provide the final byte (+headers). We also figured out that ranges of Content-Encoding is somehow ambiguous (not in terms of the spec), but basically browsers don't trust the behavior of the server and vice versa (with the exception of Chrome which is the only browser that attempts heuristically to deal with it at all). We've also seen that servers and clients have changed their interpretation over time. Our motivation was to clarify that situation and allow browsers and servers to support more features, specifically in recovering from broken transfers.



Chris & Keith



[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0115.html



This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.