Subject: Another CONTINUATION Proposal

From: Jeff Pinner <[email-masked]>
Date: Tue, 1 Jul 2014 08:14:58 -0700

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?

---

From: Jason Greene <[email-masked]>
Date: Tue, 1 Jul 2014 14:53:22 -0500

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

Do headers still share state in this proposal?

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

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 1 Jul 2014 13:03:49 -0700

> Do headers still share state in this proposal?

This still would require HEADERS blocks to be contiguous since it
doesn't include any changes to HPACK.

It does however set the ground work for both:

1) adding flow-control to HEADERS (they now are separate from stream
life-cycle events)
2) interleaving non-HEADERS blocks with HEADERS blocks since the state
is only shared between one frame type

---

From: <[email-masked]>
Date: Tue, 8 Jul 2014 21:34:56 +0000

On 01 Jul 2014, at 17:18, "[email-masked]" <[email-masked]> wrote:
> [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.

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 8 Jul 2014 14:50:41 -0700

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

Correct, we'd have to remove the header block form PUSH_PROMISE so
that it only changed stream state. Push streams would now look like:

PUSH_PROMISE 1*HEADERS SYN_STREAM 1*HEADERS 0*DATA (DATA 0*HEADERS)

where the first set of HEADERS frames contained the request header
fields, the second set the response header fields, and the third
optional set the response triailers