[MDA2AV]

What was wrong

• A HEADERS frame on a stream whose request is still arriving was taken as another header block, whatever its flags. On a buffered stream its fields were decoded into the arena the body was being appended to.
• AppendBody grows one range and assumes the body is contiguous. The range then ran across those header bytes, and as many bytes fell off the body's end.
• A POST with 400 B of DATA, then x-a: abc in a HEADERS without END_STREAM, then 400 B more reached its handler with a body of 800 B, x-aabc at offset 400, and its last 6 bytes missing.

RFC 9113 8.1 makes such a request malformed. Details are in #502.

The fix

A HEADERS without END_STREAM on a buffered stream that is already open resets that stream with PROTOCOL_ERROR. Its block is still decoded, to keep HPACK in step, through the path that already does that for a refused stream's block.

A streamed body already decodes such a block aside and drops it, so that path is unchanged.

Behaviour

• Such a request is now reset, and no handler sees it. Trailers, which do carry END_STREAM, are unchanged.
• This also closes the repeated-HEADERS route to the HPACK bomb in http2: nothing bounds what a header block decodes to, so a client that sends 187 KiB pins over 1 GB (HPACK bomb) #507, though the count in http2: what a request's header blocks decode to is bounded by MaxHeaderListSize, so a client can no longer pin a gigabyte with 187 KiB #510 covers it too.

API

None.

Tests

New in the Unit suite (Http2TrailerTests.cs):

• h2 buffered request: HEADERS without END_STREAM after the opening block resets the stream, and its body never reaches a handler
• h2 buffered request: HEADERS without END_STREAM split over CONTINUATION still keeps HPACK in step
  • Both then send a request that refers to a field the dropped block inserted into the table, and check that it decodes.

Against main's ioxide.http2 (the tests only):

FAIL  h2 buffered request: HEADERS without END_STREAM after the opening block resets the stream, and its body never reaches a handler: expected [1 PROTOCOL_ERROR], got []
FAIL  h2 buffered request: HEADERS without END_STREAM split over CONTINUATION still keeps HPACK in step: expected [1 PROTOCOL_ERROR], got []
6 passed, 2 failed, 0 skipped

Each was also run against a mutation of the code it guards and failed there: no reset, and the block not decoded (COMPRESSION_ERROR on the next request).

With the fix:

• Unit: 147 passed.
• E2E: 453 passed.
• Chaos: 83 passed.
• Http: 95 passed.

Bench

None. The new branch is on a HEADERS frame for a stream already open, which a normal request only reaches for its trailers.

Fixes #502.