http.request regression > v16 regression, 400 Bad Request is thrown when GET http.request has a payload

[sliftist]

Version

v16.16.0 serverside, v20.13.0 clientside

Platform

Linux intmrovpn 5.4.0-176-generic #196-Ubuntu SMP Fri Mar 22 16:46:39 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux (serverside), Darwin **********.local 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:11:05 PDT 2024; root:xnu-10063.101.17~1/RELEASE_X86_64 x86_64 (clientside)

Subsystem

http

What steps will reproduce the bug?

const https = require("https");
async function main() {
    await new Promise((resolve, reject) => {
        let httpRequest = https.request(
            "https://intmrovpn.com/",
            {
                method: "GET",
            },
            async httpResponse => {
                let data = [];
                httpResponse.on("data", chunk => {
                    data.push(chunk);
                });

                await new Promise(resolve => {
                    httpResponse.on("end", resolve);
                });

                if (!httpResponse.statusCode?.toString().startsWith("2")) {
                    reject(new Error(`Error, ${httpResponse.statusCode} ${httpResponse.statusMessage}\n` + Buffer.concat(data).toString()));
                } else {
                    resolve(Buffer.concat(data));
                }
            }
        );
        httpRequest.on("error", reject);
        httpRequest.write(Buffer.from("{}"));
        httpRequest.end();
    });
}
main().catch(e => console.error(e)).finally(() => process.exit());

How often does it reproduce? Is there a required condition?

v20.13.0 clientside, and v16.16.0 (running a NodeJS server) serverside.

v18 clientside worked, and the errors only started happening after updating to v20.

What is the expected behavior? Why is that the expected behavior?

Ideally there wouldn't be an error. I think the error is due to a combination of the serverside NodeJS https.Server, and the clientside https.request function.

If resolving the error is impossible, a quick fix would be to add a warning when "GET" requests have a body written to them. Otherwise this bug can be almost impossible to debug. The server receives the request, and the request handler is called, but then while the handling is still running (after the first async delay) the client receives a 400.

Fixing this, or adding a warning, would hopefully prevent the next poor soul from spending hours debugging where the blasted 400 error is coming from.

What do you see instead?

Error, 400 Bad Request

Additional information

No response