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

On Apr 20, 2014 8:17 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
>

This is the first time I've seen such a level of simultaneous action from
implementers, combined with the closest thing to a "clean slate" I've ever
seen in http -- especially regarding transport issues. If this isn't the
time to get people on board and collectively do things properly, I don't
know what is.

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

Do you mean compared to hop-by-hop, or to no compression at all? To which
known abuse do you refer?

In either case, I suspect that widely supported *explicit* end to end
encoding would also suffice.

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

Not reasonable if C-E compression is mandatory. We don't make them work
harder, we put them in a situation where they *cannot* proceed; effectively
fragmenting the web into HTTP2 bits and "lame" bits. Maybe we say "sucks
for them", their fault for being the way they are, but I don't want the
http2 message to be "you can only join in if you're worthy".

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

Normally I'm happy for status quo, but the current text contains an
oversight. The only real alternative is to remove the "MUST support" for
gzip C-E -- that's the part that breaks the protocol. If anyone is still
desperate for compression then only place we're able to add it is in the
transport/framing layer.

Received on Saturday, 19 April 2014 23:06:55 UTC