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

Re: Porting T-E to HTTP/2: Reasons Against

From: Roberto Peon <grmocg@gmail.com>
Date: Thu, 10 Apr 2014 17:07:25 -0700
Message-ID: <CAP+FsNfR90Rn1C-W6Y=9cqVfMmBxK89n2H1h5o_pgPxNgQGMqg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Agreed. Additionally:

7. It provides an additional uncontrolled venue for requiring endpoints to
allocate memory.

-=R


On Thu, Apr 10, 2014 at 4:59 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> There's been a lot of email on this topic.  I want to just summarize
> the reasons for not doing this briefly and to reiterate that I don't
> think that this is a good plan.  We have, on a few occasions, opted
> for less than feature parity with HTTP/1.1, and I see this as a very
> good example of a feature we don't need.
>
> 1. We decided once already not to do this.  SPDY had the feature, we
> explicitly cut it. [1]
>
> 2. It's a very late stage to be adding features.
>
> 3. The proposal we have (Matthew's) would need significant work to get
> all the details right.  In particular, the negotiation portion would
> require some work, particularly as it relates to intermediaries.
>
> 4. T-E (other than chunked) is a seldom used feature in HTTP/1.1.
> I've seen no evidence that a congruent feature in HTTP/2 would be any
> different.
>
> 5. This feature would require serious work on the security
> implications.  The main concern here is similar to the one that has
> pretty much lead to the removal of generic compression from TLS 1.3
> [2].  This enables compression that is removed from the contextual
> information necessary to determine that compression is safe from
> attacks like BEAST [3].
>
> 6. I haven't seen strong interest in implementing this from many
> people on this list, other than a few.  Many of these concerns are
> surmountable if a widely used implementation planned to implement the
> feature (think browser, OS, server stack).
>
> In short, while I can see some marginal benefits [4], I don't believe
> that we need this feature in HTTP/2.
>
> --Martin
>
> [1] https://github.com/http2/http2-spec/issues/46
> [2] http://www.ietf.org/mail-archive/web/tls/current/msg11619.html
> [3] https://blog.torproject.org/blog/tor-and-beast-ssl-attack
> [4] I think that T-E leading to worse compression than C-E supports of
> my conclusion.
>
>
Received on Friday, 11 April 2014 00:07:55 UTC

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