- From: Matthew Kerwin <matthew@kerwin.net.au>
- Date: Sun, 20 Apr 2014 09:06:27 +1000
- To: Patrick McManus <pmcmanus@mozilla.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Mark Nottingham <mnot@mnot.net>
- Message-ID: <CACweHNADRxh=w8DM5Lhv5ezD_rZKsZoAV6dRCgfd3W7-7LqWEQ@mail.gmail.com>
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