Re: Another CONTINUATION Proposal

On 01 Jul 2014, at 17:18, "jpinner@twitter.com" <jpinner@twitter.com> wrote:
> 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
>
> [snip]


My understanding is that the problem with PUSH_PROMISE modifying the stream state isn't just that it's changing the state of a stream, but also because it's changing the hpack state. In other words, moving the headers to a different frame type doesn't solve the issue that a frame carrying hpack header blocks changes shared state.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Tuesday, 8 July 2014 21:39:57 UTC