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