Original text:
Any number of HEADERS frames can may be sent on an existing stream at any time. <del> The HEADERS frame does not define any type-specific flags. </del>  <del> The body of a HEADERS frame contains a HeaderBlock. </del>  The HEADERS frame is associated with an existing stream.  If a HEADERS frame is received with a stream identifier of 0x0, the

Reviewer comments:
Replaced 'body' with 'payload' in instances where it would be confusing. Added a flag in the HEADERS frame for header continuations. Added pointers in HEADERS+PRIORITY and PUSH_PROMISE which reference the flags in the HEADERS frame. This should
The continuation bit is inverted with respect to the FINAL flag. Is HEADER_END a better choice? Also, if an unbounded number of frames are permitted, then you need some way to place an upper bound on size. Especially since this requires* that all frames be assembled before processing. Currently, there isn't a default maximum, a setting or an error code.
It could be. I chose this polarity so that it was immediately compatible with what implementations do today for SPDY/2/3 (they don't know about such a bit). If I recall correctly, there currently isn't an explicit limit on header size in HTTP. Unless we're willing to impose such, it is up to the implementation to reject things which are too large by RESETTING the stream. That case probably does need more expounding, though.
Let's move this discussion to the list.
NAME suggested that his header compression () would include the ability to continue header blocks across frames. We should track this as a separate issue. Important consideration is the way that header blocks mutate session state (for header compression). Interleaving of continued header frames will cause issues if we don't address this. We should also consider whether this is a general facility or not.
I believe we should fix this by declaring that, if there is a continuation happening, no new headers frame is allowed to be sent until the continuation is finished. It just gets too difficult to deal with otherwise. , martinthomson EMAIL:
To clarify - you mean that no headers frame on a different stream can be sent?
yes. It isn't the only possible solution, but it is relatively simple and it seems like it should be a rare enough case... -=R , Mark Nottingham EMAIL:

Revised text:
Any number of HEADERS frames can may be sent on an existing stream at any time.  <ins> Additional type-specific flags for the HEADERS frame are: </ins>  <ins> Bit 2 being set indicates that this frame does not contain the entire payload necessary to interpret the HEADERS data.  The payload in any series of headers frames is only interpretable when HDR_CONTINUES has NOT been set, and then only when concatenated with the payload from the unbroken series of HEADERS frames where HDR_CONTINUES was set.  When this bit is set for a HEADERS frame on a particular stream (A), HEADERS frames MUST NOT be sent on other streams until a HEADERS frame has been sent on the same stream (A) where the HDR_CONTINUES bit is unset. The payload of a HEADERS frame contains a HeaderBlock. </ins> The HEADERS frame is associated with an existing stream.  If a HEADERS frame is received with a stream identifier of 0x0, the