content-length request header parsing accepts malformed values and normalizes them instead of rejecting them

[trivikr]

Bug Description

Request content-length validation is too permissive

undici/lib/core/request.js

Line 487 in a1d6766

request.contentLength = parseInt(val, 10)

The header value is parsed with parseInt(val, 10) and only checked with Number.isFinite(), which silently normalizes malformed values instead of rejecting them.

Reproducible By

import { request } from "undici";
import { createServer } from "node:http";

const values = ["1.1", "10abc", "-1", "asd"];

const server = createServer((req, res) => {
  console.log("received header:", req.headers["content-length"]);
  res.end("ok");
});

server.listen(0, async () => {
  const origin = `http://localhost:${server.address().port}`;

  for (const value of values) {
    try {
      await request({
        origin,
        path: "/",
        method: "POST",
        headers: { "content-length": value },
        body: "a",
      });
      console.log(value, "=> success");
    } catch (err) {
      console.log(value, "=>", err.name, "|", err.message);
    }
  }

  server.close();
});

Expected Behavior

Malformed content-length values should be rejected immediately with InvalidArgumentError('invalid content-length header').

In particular, values such as '1.1', '10abc', and '-1' should not be parsed or normalized into valid internal numeric values, and the request should not be sent.

Logs & Screenshots

received header: 1
1.1 => success
10abc => RequestContentLengthMismatchError | Request body length does not match content-length header
-1 => RequestContentLengthMismatchError | Request body length does not match content-length header
asd => InvalidArgumentError | invalid content-length header

Environment

macOS 26.4.1
Node v24.14.1
undici v8.1.0