Version

24.6.0

Platform

Darwin LM0E7Q05Q 24.6.0 Darwin Kernel Version 24.6.0: Mon Aug 11 21:14:08 PDT 2025; root:xnu-11417.140.69.701.11~1/RELEASE_ARM64_T8103 arm64

Linux 5.10.235-227.919.amzn2.x86_64 #1 SMP Sat Apr 5 16:59:05 UTC 2025 x86_64 GNU/Linux

Subsystem

http

What steps will reproduce the bug?

In some cases when server returns double response, HTTPParser can enter invalid state. It parses two responses consecutively from one chunk of socket data, and replaces completed IncomingMessage with partial one. Therefore, in onSocketData freeParser is not called.

This creates an issue for GC, because now ClientRequest@1, socket@1, IncomingMessage@1, IncomingMessage@2 are all tangled with HTTPParser@1 and never cleaned up.

To add more to confusion, InomingMessage@1 properly ends, emitting 'end' event and initial request finishes successfully, so there are no errors or timeouts

This can happen when body is sent with GET request. AWS ELB, for example, treats body as separate request and responds with second "Bad Request" response. If unlucky with packets, trailing data from first response and second Bad Request will arrive in same chunk in socket and create the issue.

Running attached script node --expose-gc --trace-warnings leaky-request.js reliably reproduces the issue.

leaky-request.js

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

Running attached script node --expose-gc --trace-warnings leaky-request.js reliably reproduces the issue.

In production it depends, in our case we've got ~10 stuck request out of ~150k. If we take only ones with response size > 64Kb - then 10 out of ~2.5k. Larger response have much higher chance of trailing data from first response and second "Bad Request" response being in the same chunk.

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

HTTPParser and http module in general handles these cases gracefully without leaks

What do you see instead?

ClientRequest are leaking

Additional information

The issue reproduces on v24, v22 and v20