Re: Our Schedule

Hi,

I have discussed HTTP 2.0 status with Greg, and below you can find my thoughts.

On Sat, May 24, 2014 at 11:43 AM, Greg Wilkins <gregw@intalio.com> wrote:
> There is no clear layering of the protocol. SPDY has a well defined framing
> layer that can be separately implemented and tested.  HTTP is only a
> semantic layered on top of that framing layer.  HTTP/2 should do the same
> and it is a MASSIVE mistake verging on hubris to give up this fundamental
> good protocol practise in the name of speculative efficiency gains.

This is IMHO the primary mistake.
The framing should be very simple, define stream start and end, and be
completely detached from the HTTP semantic.
The HTTP semantic should be defined on top of the framing.

> The state machine in section 5.1 is essentially a fantasy that describes an
> idealised protocol that the draft does not represent.   In my work I very
> frequently lookup the TCP/IP state machine diagram that is a great reference
> and rarely do I need to go beyond it to understand any issue I have.
> However, if developers with HTTP/2 problems try to use the state machine in
> 5.1 as a reference, they are only going to be more confused. For example,
> the ES transitions are not atomic and the closed state is described as "the
> terminal state", but is then followed by 5 paragraphs of dense complex text
> describing exceptions and how some frames received in closed state have to
> be handled!  I have posted what I think is the real state machine
> (http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/att-0720/http2state.txt)
> and it is a much more complex beastie.

I am worried about the diagram posted by Greg above. The number of
ways it could be implemented wrongly is large.
The more complex it is, the more chances of coding mistakes, attack
vectors and such.
I don't see any reason it should be so complex: closing a stream
should be similar to closing a TCP stream.

Note that there need not to be any additional semantic to
server-to-client opened streams.
The stream framing should be symmetric, and PushPromise is just a
layering of HTTP semantic on top of a server-to-client initiated
stream.
The raw SPDY framing can be used to transport something that is not
HTTP, and I have actually implemented something that transports JSON
data with no headers that is fully bidirectional.
Jetty exposes a fully symmetric SPDY-only API without binding to HTTP:
clients can open streams, and servers can open streams.

I am of the opinion that splitting the framing from the HTTP semantic
will provide many benefits, simplifying the protocol and improve HTTP
2.0.

Regarding compression of headers, I'd rather see it negotiated and off
by default. I think it is something nice to have but not absolutely
necessary.
For example in SPDY, where header compression is not that complex and
based on libraries widely available for any language (deflate), I
think the issue of header compression is nonetheless the #1 question /
problem / roadblock for SPDY implementers. HTTP 2.0 should simplify
this, not making it more complicated.

Finally, despite its limits, HTTP 1.x has been one of the most
successful protocols ever.
I would like to see HTTP 2.0 surpass it, by iteratively removing and
simplifying until there is nothing left to take away.

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

Received on Monday, 26 May 2014 17:02:10 UTC