Re: #445: Transfer-codings

+1

I don't care much on how the compression is signaled.

On 04.04.2014 20:41, K.Morgan@iaea.org wrote:
>
> 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.
>