Content of continuations

[martinthomson]

HEADERS and PUSH PROMISE can have their header block fragmented among multiple contiguous frames. That's clear.

For PP I'm a ltitle unusure how Promised-Stream-ID fits into those fragments. Is it present in all of them? the frame diagram seems to assert that it is present in every PP frame, but the definition of END_PUSH_PROMISE says "the payload of all PUSH_PROMISE frames are concatenated and interpreted as a single block". and the Promised-Stream-ID is definitely part of the definition of payload (which we have defined as everything after the first 8 bytes of frame header).

The right thing is probably that it is present in all of them, but is not considered part of the payload for purposes of determining the header block. A clarification seems needed. If that's right, do we need a rule saying the Promised-Stream-ID must be the same across all the fragments?

I think HEADERS has a similar problem with Priority.. it uses a "payload" definition of the headers block that would include priority (but shouldn't)...

So, what is the content of a continuation?

[martinthomson]

Comment at the meeting:

It's possible that an encoder could place only a small number of bytes in a frame and then use continuations. This was identified as a pathological case that would be a good addition to a test suite.

[martinthomson]

There seemed to be a general desire to define a ...CONTINUED frame that doesn't have any of the decoration that the initial frame in the continued sequence has, like the PRIORITY bit, or the promised stream identifier. Hasan might produce a proposal.

[martinthomson]

Note: Frames without END_HEADERS MUST NOT have END_STREAM.

[mnot]

Discussed in Hamburg; agreed that we need:

• a generic CONTINUATION frame
• a continued flag

and more, as above

[jasnell]

+1 on the CONTINUATION frame...

(see http://lists.w3.org/Archives/Public/ietf-http-wg/2013JulSep/0527.html)

[aamelnikov]

Will the following sequence of frames be legal on a stream: PUSH_PROMISE, HEADERS, CONTINUATION?

In the section:

  <section anchor="PushResources" title="Server Push">

I see:

The server SHOULD send <xref target="PUSH_PROMISE">PUSH_PROMISE</xref> frames prior to
sending any HEADERS or DATA frames that reference the promised resources.  This avoids
a race where clients issue requests for resources prior to receiving any PUSH_PROMISE
frames.

which made me think that at least the following sequence of frames is legal: PUSH_PROMISE followed by HEADERS. I am not sure this is very clear elsewhere in the document.

[martinthomson]

Yes, this is a valid sequence. I believe that the full sequence (as ABNF) is:

response = *(push-promise *continuation) headers *continuation *(data / ((headers / push-promise) *continuation)) [headers *continuation]

Note: the last frame of a response can now be a (continued) push promise, since that now has END_STREAM. We need to fix that. I'll follow up on-list and maybe raise another issue.