Fixed HTTP request body problems escaping as exceptions or echoing the body - #634

Problem

The ASP.NET Core request handler turned request body problems into unhandled exceptions (a 500 under most hosts), or into a 400 that repeated the body back:

• Unparsable multipart body: a missing or unused boundary, a truncated body or a malformed part header threw InvalidDataException or IOException out of HandleAsync.
• Body too large: a body over Kestrel's MaxRequestBodySize threw BadHttpRequestException out of HandleAsync.
• Missing operations field: a form request without it got a 400 that repeated the whole multipart body, files included.
• Invalid JSON: the 400 for a body that is not valid JSON repeated the body in its received member.

Changes

• 400: a body the form reader cannot parse gets 400.
• 413:
  • a body over MaxRequestBodySize: every BadHttpRequestException gets the status code the server gives;
  • a body over a size limit of FormOptions: multipart body, headers length or count, value count, key or value length, and buffer.
• Telling limits from malformed bodies: the form reader reports both with the same exception, so only messages that start with the prefix of a size limit get 413. A boundary parameter over its length limit, a delimiter line followed by other text, and a malformed part header, whose text the client controls, get 400.
• Boundary too long for the reader's buffer: this needs a raised MultipartBoundaryLengthLimit. It now gets 400, instead of an ArgumentOutOfRangeException whose message repeats the boundary.
• Missing operations field: the 400 names the missing field.
• map field: it must be a JSON object of non-empty arrays of variables. paths, else 400. Its keys are not checked against the file fields, because the client of this library keys the map by index but names the file fields by upload name.
• Breaking: the 400 for invalid JSON no longer has received, and every reason quoted from the deserializer, the form reader or the server is cut to 256 characters.

Tests

The tests are xUnit, in the new RequestBodyTests.fs and in RequestHandlerExtensibilityTests.fs:

• multipart: a missing, unused, over-long or buffer-exceeding boundary; a truncated body; malformed part headers; a malformed delimiter line; a missing operations field; invalid maps;
• size limits: form body, value count and buffer limits, and the server's limit;
• echoing: no response repeats the body;
• the client's multipart format is still executed.

Reverting the source makes them fail.

An independent review tried many more bodies in process and on a real Kestrel host. None gave a 500 or echoed the body or a file:

• truncated, unbounded and over-limit bodies, chunked or not;
• non-UTF-8 and BOM bodies;
• every kind of JSON value as the body;
• URL-encoded forms.

All 46 upload integration tests pass with the real client provider.

Verification:

• Unit tests: the whole project passes, 801 tests with 5 skipped.
• FAKE: the full pipeline passes, including the integration tests.

Left for later

These are not changed here:

• Bodies buffered but never read: checkIfHasBody judges such a body by its length, which is 0 until it is read. A query sent after a middleware called EnableBuffering() without reading the body gets the introspection result instead of being executed.
• Buffer limit: through HandleAsync, FormOptions.BufferBodyLengthLimit is never reached, because the handler buffers the body without a limit first.

🤖 Generated with Claude Code