Re: HTTP 2.0 and a Faster, more Mobile-friendly web

>2. Multiplexing
>
>All three proposals define similar multiplexing models. We haven't had
>substantial discussion on the differences. This lack of discussion suggests
>that there is rough consensus around the SPDY framing for multiplexing.

... or that more important topics have stolen the time.

(Absense of evidence is not evidence of absence.)

>There is definitely no consensus to mandate TLS for all Web communication, 
>but some major implementers have stated they will not to adopt HTTP/2.0 
>unless the working group supports a "TLS is mandatory" position.

It is not clear to me exactly what these major implementers mean when
they say "TLS is mandatory"

Do they mean "TLS MUST be supported" or "TLS MUST be used" ?

It is also not clear to me which property of TLS they are after, is
it identification, authentication, secrecy or privacy they want ?

I also wonder about their motives:  Do they really insist on TLS
in order to shut out intermediaries ?

>5. Client Pull and Server Push
>
>There are tradeoffs between a server push model and a client pull model. 
>The main question is how to improve performance while respecting bandwidth 
>and client caches.

I would Server Push for HTTP/2.1, but keep an eye out for what it will
need while designing HTTP/2.0.

>6. Flow Control
>
>There has only been limited discussion in the HTTPbis working group on flow
> control. 

One very important aspect of flow control is DoS mitigation, and we have
barely mentioned that until now.

It would be a great step forward in DoS resistance if HTTP/2.0 put
a very tight limit on the initial "resource window" the client can
use, in order to give the server maximum control over allocation
of resources, from the very begining.

If the limit was set around "max 1 connection, max 6 pipelines requests
no request bodies larger than 4k" until the server says otherwise,
DoS attacks against HTTP/2.0 will be easier to cope with.


I too agree that all three proposals bring good things to the table,
but I think we would be better off starting from scratch, cherry picking
from the three suggestions as we go along, rather than try to evict
text already added to one of the proposals.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Monday, 30 July 2012 07:03:11 UTC