Porting T-E to HTTP/2: Reasons Against

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:00:28 UTC