Ignore trailers on a stream we have reset - #224

Problem

RFC 9113 §5.1: "An endpoint MUST ignore frames that it receives on closed streams after it has sent a RST_STREAM frame."

A peer that sends a body followed by trailers (gRPC, for example) may already have sent the trailers when our RST_STREAM reaches it. The server, however, removes a stream from the table when it resets it. HEADERS arriving on that stream ID afterwards were treated as reuse of a stream identifier, which is a connection error, so every other stream on the connection was lost too.

Fix

• closed records the IDs of peer-initiated streams that the server resets (ResetByMe). It keeps the latest 1000 IDs and forgets the oldest first. Server only.
• In getOddStream, HEADERS and CONTINUATION on a remembered stream are ignored. Their field block still goes through hpackDiscardHeader, so the HPACK dynamic table stays in sync.
• HEADERS on any other closed stream is still a connection error.

Tests

New tests in test/HTTP2/ServerSpec.hs:

• Ignored trailers. The server resets a request whose body outgrows its content-length (Check the body against its content-length before delivering it #223). The client's trailers then arrive, carrying a field with incremental indexing, and the next request refers to that dynamic table entry. Expected: RST_STREAM 1 ProtocolError, then HEADERS 3, with no GOAWAY. This covers both a single HEADERS frame and HEADERS split with a CONTINUATION.
• Regression guard. After a response has completed normally, HEADERS on the same stream still gets GOAWAY ProtocolError.

Checks:

• Without the fix, the first test fails with a GOAWAY.
• Without CONTINUATION handling, the split case fails.
• Ignoring every HEADERS on closed streams makes the guard fail.
• Both tests passed 20 out of 20 runs under CPU load.
• cabal test all passes, and I ran it three times. There are no compiler warnings.

🤖 Generated with Claude Code