W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

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

From: Nicholas Hurley <hurley@todesschaf.org>
Date: Sat, 19 Apr 2014 16:43:43 -0700
Message-ID: <CANV5PPX-V2h1bKbbTdR9HDkf-Bd7DPz0sEK+rMUJ0HgLb63ASQ@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
+1 to everything Patrick has said.

If, however, we end up doing some sort of (ill-advised) hop to hop transfer
encoding, then it should absolutely be (1) optional, and (2) opt-IN (not
opt-out, as Matthew's branch has it)

On Sat, Apr 19, 2014 at 3:15 PM, 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
>  * 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/

Received on Saturday, 19 April 2014 23:44:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC