Re: Streaming layer in HTTP/2.0

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


On Thu, Feb 21, 2013 at 2:58 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

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