Re: Why do HTTP/2 CONTINUATION frames not have an END_STREAM flag?

It reads like you can send the END_STREAM flag on the HEADERS frame,
without END_HEADERS, and then send CONTINUATION frames, and when they end,
the stream ends.

https://httpwg.org/specs/rfc9113.html#HEADERS

> A HEADERS frame with the END_STREAM flag set 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.

On Mon, Mar 2, 2026, 4:39 PM Lucas Pardue <lucas@lucaspardue.com> wrote:

> Hi folks,
>
> I was looking again at HTTP/2 frames and realized that CONTINUATION frames
> don't have an END_STREAM flag. Knowing why this is the case is not critical
> to anything but it got me curious.
>
> Its possible to send HEADERS with END_STREAM=1, to send a request or
> response with no DATA frames at all. However, it seems any stream that uses
> CONTINUATION but has no HTTP content to send would have to use a sequence
> like:
>
> 1. HEADERS (END_HEADERS=0, END_STREAM=0),
> 2. CONTINUATION (END_HEADERS=1),
> 3. DATA (LENGTH=0, END_STREAM=1).
>
> Empty DATA frames to signal stream close are not themselves a problem. The
> deployments I'm familiar with regularly send them.
>
> However, this raises an issue for anyone that might try to use
> CONTINUATION in trailers. You can't can't clean close the stream:
>
> 1. HEADERS (END_HEADERS=1, END_STREAM=0),
> 2. DATA (END_STREAM=0),
> 3. HEADERS (END_HEADERS=0, END_STREAM=0), CONTINUATION (END_HEADERS=1)
> 4. Not valid to send DATA again, oops
>
> Cheers,
> Lucas
>