> On 15 Apr 2020, at 18:17, Daniel Fuchs <[email protected]> wrote:
>
> Hi Chris,
>
> On 15/04/2020 17:40, Chris Hegarty wrote:
>> It is allowable for a HEADERS frame to carry an END_STREAM,
>> but not an END_HEADERS. If this happens, then CONTINUATION
>> frames must follow, the last of which will carry END_HEADERS.
>> That probably explains why the END_STREAM handling is done
>> the way that it is.
>
> That does not make sense. If there is END_STREAM there cannot
> be any continuation frames since the stream will be closed.
From section 6.2 - HEADERS:
END_STREAM (0x1): When set, bit 0 indicates that the header block
(Section 4.3 <https://tools.ietf.org/html/rfc7540#section-4.3>) is the
last that the endpoint will send for the
identified stream.
A HEADERS frame carries the END_STREAM flag that signals the end
of a stream. However, a HEADERS frame with the END_STREAM flag
set can be followed by CONTINUATION frames on the same stream.
Logically, the CONTINUATION frames are part of the HEADERS frame.
-Chris.
[1] https://tools.ietf.org/html/rfc7540#section-6.2
