Re: Another CONTINUATION Proposal

On Jul 1, 2014, at 10:14 AM, Jeff Pinner <jpinner@twitter.com> wrote:

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

Do headers still share state in this proposal?

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Tuesday, 1 July 2014 19:53:52 UTC