Another CONTINUATION Proposal

I have a slightly different proposal for removing CONTINUATION frames.

Note that this does not consider flow control of header fields but it
would begin to enable it.

One of the initial reasons we decided to use CONTINUATION frames over
multiple HEADERS or PUSH_PROMISE frames was because besides carrying
the header block, these frames could change stream state. As an
example, PUSH_PROMISE reserves an stream in the idle state and we
didn't want to send a PUSH_PROMISE stream with an id of an already
reserved stream.

We could instead separate frames that contain header fields from those
that operate on stream state. This would mean modifying the
PUSH_PROMISE frame so that it only reserved a stream, and introducing
a new frame, say SYN_STREAM, that only transitioned a stream from the
idle or reserved states to open or half-closed.

So then we would have the following frames that manipulate stream
lifecycle that do NOT have priority or header block fields:

PUSH_PROMISE
SYN_STREAM
RST_STREAM

Then only the HEADERS frame would carry a header block and have no
flags for priority (priority information is no longer required in this
frame since we have no removed the race condition between opening the
stream and sending priority information on it, that is, we can send
SYN_STREAM, PRIORITY, HEADERS so we don't need to include the
information in the frame).

HTTP Message can then be encoded as:

SYN_STREAM 1*HEADERS *DATA *HEADERS

where the END_HEADERS and END_STREAM frames on HEADERS show up on the
"correct" frames.

Server PUSH is then encoded as:

PUSH_PROMISE 1*HEADERS SYN_STREAM 1*HEADERS *DATA *HEADERS

Thoughts?

Received on Tuesday, 1 July 2014 15:15:25 UTC