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

On 20.04.2014 00:15, Patrick McManus 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
True
>  * implicit end to end content encoding improves a known abuse of the 
> protocol.
I see it differently, e.g. mandating C-E casts a known abuse of the 
protocol in concrete
>
> Sure, that makes http/2 gateways have to work a little harder with 
> lame http/1 clients. that's a reasonable price.
>
In a pure http/2 world intermediaries will do the same, e.g. do dynamic 
C-E gzip the same way as they do now.
> 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 :)
>
Considering doing C-E and T-E gzip on the whole file the compressed bits 
send over the wire are the same, so when there is a security issue with 
one of it shouldn't it apply to the other as well?

Regards,
Roland

> -P
>
>
>
> On Fri, Apr 18, 2014 at 2:52 AM, Mark Nottingham <mnot@mnot.net 
> <mailto: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/
>
>
>
>
>