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

+1 to everything Roberto and Martin have said. I have no intention of
implementing this (were it to make it into the spec), for my part.


On Thu, Apr 10, 2014 at 5:07 PM, Roberto Peon <grmocg@gmail.com> wrote:

> 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.
>>
>>
>


-- 
Peace,
  -Nick