[MDA2AV]

Fixes #63

Why

ParserLimits caps the header block, but nothing caps a chunked body's framing:

• (a) ChunkedBodyStream returns NeedMoreData until a whole chunk is in the buffer. A peer that declares FFFFFFFF and keeps sending makes the caller's buffer grow without limit.
• (b) The trailer section has no cap. Endless X: y lines after the last chunk bypass MaxTotalHeaderBytes. Because NeedMoreData rolls back, the decoder also asks for the whole section to be re-presented until it ends, so the trailers get buffered too.

What changes

Chunk data is handed out as it arrives (span and ReadOnlySequence overloads):

• A Chunk result now carries a whole chunk or the part of one that has arrived. It is never empty.
• Data that is complete before its CRLF is handed out too; the CRLF is checked on the next call, and a bad one still throws Missing CRLF after chunk data..
• NeedMoreData keeps its contract: nothing is consumed, the state is rolled back, and the caller re-presents the same bytes. It now only happens when not a single data byte is available, for example a size line with no data after it yet.
• Buffering is bounded by the caller's read window, not by the declared size. The C decoder already works this way.

The trailer section is capped:

• New ParserLimits.MaxTotalTrailerBytes, default 16 KiB. It counts every trailer field line after the last chunk, including its CRLF.
• Exceeding it throws HttpParseException("Chunked trailer section exceeds limit.", 431) from both stream overloads and from ChunkedBodyValidator.
• The bytes seen so far are checked even while the section is incomplete, so an endless section is refused once it passes the cap instead of being re-presented forever.
• A CR at the very end of the input is not counted yet, since it may be the first half of the final CRLF. Without that, a section exactly at the cap whose last CRLF arrived split across reads would be refused by mistake.
• Limits are passed in two new ways: a ChunkedBodyStream(in ParserLimits) constructor and a ChunkedBodyValidator.TryValidate(body, in ParserLimits, out consumed) overload. new ChunkedBodyStream(), default(ChunkedBodyStream) and the existing TryValidate overload apply ParserLimits.Default, so existing callers get the cap without code changes.

No cost on the common path:

• The two new fields sit in the padding after the byte-sized phase, so the decoder state stays 32 bytes, as on main. It is copied on every call for the NeedMoreData rollback.
• The ReadOnlySequence overload marks sliced chunk data with a flag instead of testing ReadOnlySequence.IsEmpty on every chunk.
• In pinned, alternating BenchmarkDotNet rounds against main, multi-segment chunked decoding was about 7% slower without these two changes and is within noise with them.

Docs: the limits tables in SECURITY.md and on the site, the chunked section of the site (its NeedMoreData comment said "partial chunk"), and one line in the README.

Decisions worth reviewing

• Chunk no longer means "one whole chunk". Chunk boundaries carry no meaning in HTTP, and callers that append each Chunk's bytes and advance by bytesConsumed need no change. GenHTTP's ChunkedFraming is one: it copies data and advances to consumed on the sequence overload, so partial chunks pass through it unchanged. Code that assumed one Chunk per wire chunk would see more results. I found no such code. One GenHTTP test did pin whole-chunk buffering: ChunkedFramingTests.TestTruncatedBodyFails expected the first read of 5\r\nHel to fail. It now gets the three bytes first and the 400 on the next read. chore(engines): Update Glyph11 to 0.4.0 and drop Glyph11.Pico Kaliumhexacyanoferrat/GenHTTP#973 adapts it.
• No MaxChunkSize, although the issue mentions one. Once data is streamed, a per-chunk cap only rejects legitimate large chunks. Buffering is already bounded, and the total body size is the application's limit.
• An explicit MaxTotalTrailerBytes = 0 means "no trailers": 0\r\n\r\n is accepted and any trailer line is refused. This matches how the other ParserLimits fields treat 0. Only a decoder built without limits falls back to the default.

Overlap with sibling PRs

• Chunk sizes of 2^63 or more go negative: truncated, re-read as framing, or ArgumentOutOfRangeException #62 (chunk size overflow) touches the same two files, but the ChunkSize phase rather than ChunkData/Trailers. A trial merge of both branches is clean and passes the combined suite (474 tests).
• LF-only messages read as incomplete forever; bare-LF strictness is unreachable #59 also adds a property to ParserLimits (AllowBareLf), so ParserLimits.cs will need a trivial merge.

Tests

New tests/Tests/ChunkedBodyStream.Limits.cs (44 tests):

• Byte-at-a-time and random-split reassembly for both overloads over several bodies (extensions, trailers, a 1000-byte chunk, 20 random-size chunks). Each Chunk must be non-empty, NeedMoreData must consume nothing, and the decoded body must match.
• A 1 MiB chunk read 4 KiB at a time never has more than one read window buffered.
• FFFFFFFF with a few data bytes yields a Chunk, not NeedMoreData. A size line alone still yields NeedMoreData with nothing consumed.
• Data that is complete before its CRLF (none of the CRLF yet, or only the CR) is handed out, and the CRLF is validated next call.
• Trailer section at 0, 100, cap−1 and cap completes. Cap+1 and 4×cap are refused with 431 for the span overload, the sequence overload (1, 3 and 17 segments), the validator and default(ChunkedBodyStream). Custom cap (64), a zero cap, an incomplete section under the cap, an at-cap section whose final CRLF is split, an endless single line, and endless short lines are all covered. The endless lines are fed through a 512-byte read loop and refused within one read of crossing the cap.
• The decoder state is pinned at 32 bytes, so a field that grows the per-call rollback copy fails a test.

Three existing tests pinned whole-chunk buffering and were updated:

• Incremental_ChunkDataAcrossCalls now expects He then llo.
• Incremental_MultiChunkByteByByte asserts the reassembled body rather than two chunks.
• Sequence_NeedMoreData_RollsBack_ThenCompletes uses a prefix that ends before any data, so it still covers the rollback.

Full suite: 447 passing (403 before).

SonarCloud

S3776 (cognitive complexity) is reported on the new TryValidate(body, in ParserLimits, out int) overload. It is the validator's existing issue: the implementation now sits under the new signature, and the trailer cap adds to it (109 → 118).