Re: Transfer-codings, mandatory content-coding support and intermediaries

On 20 Apr 2014, at 8:15 am, Patrick McManus <pmcmanus@mozilla.com> wrote:

> nothing in this thread has really changed the basic design decisions already in the current drafts
>  * hop to hop transfer encodings have never been widely used successfully - let's get rid of them

That seems to be a widely-held belief, with a few exceptions. However, I personally think Matthew's most recent proposal is quite reasonable, especially if it flips to being opt-out. While browsers might not use them, API folks could find this quite attractive (as we're hearing from the IAEA people).

Daniel, any thoughts from a curl perspective here -- would you support a "compressed data frame" flag?


>  * implicit end to end content encoding improves a known abuse of the protocol.

Calling it "abuse" is a value judgement. While it's true that we're chartered to improve performance, those performance gains should not come at the cost of interoperability, which is what we're seeing here.

Also, since many have stated an intent to only deploy HTTP/2 over TLS, I wonder how bad this "abuse" will be. 


> Sure, that makes http/2 gateways have to work a little harder with lame http/1 clients. that's a reasonable price.

No, that's not the problem. The problem is that the gateways have to become non-transparent, making it more difficult for clients to interoperate *through* them.


> i'm in favor of the status quo here (i.e. no TE and implicit CE: gzip). The alternative seems to be some form of per frame gzip changes at this point with no implementation experience and a literal trail of tears in recent non-content-aware compression schemes when mixed with TLS. Let's not do that :)

That's a false choice. We need to deal with the interop problems whether or not we introduce hop-by-hop compression. 


> 
> -P
> 
> 
> 
> On Fri, Apr 18, 2014 at 2:52 AM, Mark Nottingham <mnot@mnot.net> wrote:
> We've had a wide-ranging discussion of the issues brought about by HTTP/2 dropping the concept of transfer-coding, in conjunction with the imposition of mandatory gzip content-coding support by clients.
> 
> At this point, it looks like the folks who have asked for TE support in HTTP/2 are willing to wait on incorporating such a feature into HTTP/2. Since we don't seem to have much consensus on any of the proposals to date, the status quo seems like a good path forward -- although I think we should discuss this in more depth in NYC.
> 
> However, discussion has also uncovered some problematic aspects of requiring clients to support GZIP content-encoding in HTTP/2.
> 
> Specifically, we're chartered to enable intermediaries to translate from 1.1 to 2 and back with reasonable fidelity. As has been noted, that's hard to do if a HTTP/1 client doesn't support gzip content-encoding; if the HTTP/2 origin assumes gzip support, the intermediary has to decompress it, and -- importantly -- assign a new entity tag to the response.
> 
> That's pretty clearly a major reduction in functionality, and effectively removes what we used to call semantic transparency from all HTTP1.x->HTTP2 proxies. As discussed, there are other side effects of this approach as well.
> 
> I've created <https://github.com/http2/http2-spec/issues/460> to track this issue. I don't think it affects the current implementation draft, but we do need to discuss it before (and likely at) the NYC interim.
> 
> Cheers,
> 
> 
> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 
> 

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

Received on Saturday, 19 April 2014 23:57:32 UTC