[MDA2AV]

What was wrong

Http3Request.AddField stored each pseudo-header it decoded, with no check of what came before. A :path repeated in a field section replaced the first, so a handler saw /admin on a request that opened with /public. A pseudo-header after a regular field was accepted, and an unknown one ignored.

RFC 9114 4.3 makes all of these malformed. Details are in #504.

The fix

• A pseudo-header's range is unset until it is seen, so a repeat needs no new state to detect, and HeaderRanges says whether a regular field came first. An unknown name, a repeat or one out of order marks the request malformed.
• OnHeadersComplete then resets the stream with H3_MESSAGE_ERROR through RefuseMalformed, as an invalid content-length already is. No handler sees it.

Trailers cannot do this here, since the connection ignores every HEADERS frame after the first. The nghttp3 stack checks these in the library.

Behaviour

A request with any of these is now reset, where it used to be served.

API

None.

Tests

New in the E2E suite (H3ErrorCodeTests.cs), over the recording transport:

• http3/codes: a repeated :method is H3_MESSAGE_ERROR on its stream, which no handler sees
  • And for a repeated :scheme, :path and :authority, a pseudo-header after a regular field, and an unknown one. In each, a well-formed request on the next stream is served and the connection stays open.
• http3/codes: a repeated :method never reaches a handler taking a body reader, and the same five others

With the check removed, as on main: all 12 fail, expected stream 0 reset with H3_MESSAGE_ERROR and nothing else, got []. Each clause was also run against a mutation that removes it, and only its own tests failed: repeats (8), order (2), and unknown names (2).

With the fix:

• Unit: 145 passed.
• E2E: 465 passed.
• Chaos: 83 passed.
• Http: 95 passed.

Merging

#492 pools a finished request, but a refused one never goes back, so Malformed needs no reset there.

Bench

Measured with the same setup as #486:

• One reactor pinned to CPU 6, and h2load -c 32 -m 16 -t 1 (with --alpn-list=h3) pinned to CPU 2.
• Main, this branch, and main again from a second worktree as a control.
• Six interleaved rounds of 10 s; each build is compared with main inside its own round.

Sample	Server CPU per request, branch vs main	Control vs main
Http3/ManagedBuffered	-2.8%	+0.1%

Inside the noise, so no cost shows. Another benchmark started on the box during the last round, where all three builds ran slow (1,758-2,003 ns); the medians hold.

Fixes #504.