RE: #445: Transfer-codings

The proposals by Matthew and Mark get the job done, but they strike us as more complex than TE/Transfer-Encoding...



A (partial) list of benefits of TE/Transfer-Encoding (over framing layer transfer coding):

     1.  TE/Transfer-Encoding doesn't require any changes at the HTTP/2 framing layer!!!

     2.  Since TE and Transfer-Encoding are headers, the decision to compress can be made closer to the application layer.

          a. i.e. this makes it easier to decide when to compress.

          b. It also makes it less likely that double compression will occur.

          c. This also covers Martin’s concern that “an entity performing compression has knowledge of what is being compressed and is therefore able to more accurately determine whether compression is safe to use.”

     3. Retains the extensibility to support new compression algorithms (with all the same benefits Matthew mentioned in [1]).

     4. With TE/Transfer-Encoding, only clients have a new requirement. Servers that don’t want to support Transfer-Encoding don’t have to do anything except ignore TE headers.

     5. Since TE/Transfer-Encoding is already part of the HTTP/1.1 spec, 1.1 clients could benefit from this compression when talking to a 1.1<->2 intermediary by implementing TE/Transfer-Encoding; relieving intermediaries of the burden to decompress; and save bandwidth.



We submit the following alternative proposal for consideration:



9.4 Transfer-Encoding



HTTP/2 retains the semantics of HTTP/1.1 regarding transfer codings (see [HTTP-p1]<http://http2.github.io/http2-spec/#HTTP-p1>, Section 4<https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/26/p1-messaging.html#transfer.codings>), with the following additional requirements. Servers MUST NOT use chunked transfer coding. Clients MUST support “gzip” transfer coding. If the "TE" request header field-value is empty or if no TE field is present, the only acceptable transfer coding is "gzip".





In earlier threads, Roy Fielding gave his support for compression transfer codings, including implicitly requiring clients to understand (decompress) gzip transfer encoding (our apologies to Roy for quoting him so often):



“I would not require [gzip transfer coding] to be used -- just make it possible to be used and required to understand (decompress by recipient).  This is what you already do with HTTP/2…” [2]



“… it isn't virtually impossible to introduce standard transfer codings.  It just requires effort by browsers to support one. It also isn't necessary to restrict HTTP/2 features to what a current browser supports.” [2]



“Transfer compression has limited deployment but actually does work when it is deployed by consenting adults.  You can change that deployment in HTTP/2. It is well within scope.” [3]





(We redact our earlier proposal [4] which had several flaws.)



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


[2] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1203.html


[3] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1189.html


[4] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1205.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.