W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Another CONTINUATION Proposal

From: Jeff Pinner <jpinner@twitter.com>
Date: Tue, 1 Jul 2014 08:14:58 -0700
Message-ID: <CA+pLO_j3qRc3kPee5FVhBZEyXmHAzv6ta2fEhf-e8vkax4kiyQ@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
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:


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:


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

Server PUSH is then encoded as:


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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:08 UTC