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

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
 * implicit end to end content encoding improves a known abuse of the
protocol.

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

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 :)

-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/
>
>
>
>
>