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

On 11.04.2014 01:59, Martin Thomson 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.
Mandating C-E gzip was added lately and actually this causes some 
problems which may be solved be T-E.
>
> 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.
It is not only about C-E vs. T-E but also about seek requests. In 
HTTP/1.1 the client has the choice to prefer range requests / responses 
over compression. In HTTP2 the client will have no choice.
>
> 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].
Actually why is C-E better here than T-E? Especially as existing proxies 
do C-E on the fly.

> 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.
>
Mandating C-E gzip breaks compatibility with existing HTTP/1.1 clients, 
so do we want to get rid of mandating compression at all?

Received on Friday, 11 April 2014 16:18:04 UTC