Subject: Streaming layer in HTTP/2.0

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Feb 2013 14:58:03 -0800

When going over the framing changes, it became rapidly apparent that
there are a number of things in HTTP/2.0 that are currently badly
inconsistent.  This makes it hard to build modular implementations and
complicates the specification.

Here are a few examples that I think could be fixed relatively trvially:

Problem: Error codes for RST_STREAM and GOAWAY are different.  Worst
case is that INTERNAL_ERROR is 6 on RST_STREAM and 2 on GOAWAY.

Resolution? These could be unified into a single set.  From what I can
tell, there is only one case where stream and session errors overlap,
so far, but this would make definition (and registration) easier.

Problem: The flags on each frame are interpreted differently based on
the frame type.  This means that there are many ways to half-close a
stream:
SYN_STREAM, SYN_REPLY, DATA, and HEADERS all define a flag with the
same semantics.  By coincidence, these all have the same value, but
code that processes streams generically cannot rely on this.

Resolution? Reserving a bit for a STREAM_FINAL flag for use in all
stream-related frames would streamline things.

(Note: The other way of closing is to mark a stream UNIDIRECTIONAL in
SYN_STREAM.  This seems special enough already.)

Problem: The 31-bit field in the frame header that usually holds the
stream ID isn't exclusively used for that purpose.  This means that
for the field cannot be generically processed.  The non-frame-related
messages that use this field (PING, GOAWAY, SETTINGS) can all use
other mechanisms.

Resolution?  Make the stream ID in the frame header always contain a
stream ID.  Non-stream-related frames set the value to the invalid
stream ID (0).
 - Have PING use the payload to provide correlation between ping and pong.
 - Have GOAWAY move the last-stream-ID to the frame payload, making
GOAWAY a massive 16 bytes, up from 12.
 -  Remove the settings count from SETTINGS, which is redundant.  The
number of settings can be inferred from the frame length.

This set of changes would allow for the discrete definition of a
streams layer in the protocol.  That layer could then be ignorant of
individual message types, with the exception of the 3 (...2) stream
control messages.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 21 Feb 2013 15:04:28 -0800

It will expand the size on the wire by a small amount for frame-types which
should be used relatively infrequently as compared to other frame-types...
so who cares :)

seems reasonable to me.

-=R