Repository navigation
http server.headersTimeout keeps the socket open after timeout #26165
Copy link
Copy link
Closed as not planned
Labels
httpIssues and PRs related to the http subsystem.Issues and PRs related to the http subsystem.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
Description
Activity
- addedhttpIssues and PRs related to the http subsystem.Issues and PRs related to the http subsystem.
on Feb 18, 2019 I tried to reproduce what is described in this issue (see attached snippets at the end), but I wasn't able to:
- When
connectionsCheckingIntervalis set to a value lower than theheadersTimeout, the timeout triggers as expected and the socket is closed. - When
connectionsCheckingIntervalis higher, then the timeout is not triggered (I first thought this might be how to get into this case), but still the socket won't get closed when it is written to. Instead, the request will just be handled is if there was no headers timeout.
This is the behavior I observed on both node 11.6.0 (report) and 22.1.0 (current) - 23.4.0 Darwin fwiw.
Repro attempt source
// server.js const http = require("http"); const server = http.createServer({ // connectionsCheckingInterval: 1000, // enable this to trigger headersTimeout },(req, res) => { res.writeHead(200, { "Content-Type": "text/plain" }); res.end("Hello, World!\n"); }); server.headersTimeout = 5 * 1000; // 5 seconds server.timeout = 30 * 1000; // 30 seconds server.listen(3000, () => { console.log("Server running at http://127.0.0.1:3000/"); });
// client.js const net = require('net'); const client = new net.Socket(); client.connect(3000, '127.0.0.1', () => { console.log('Connected to server'); client.write('GET / HTTP/1.1\r\n') // Wait 10 seconds before sending the request headers to simulate delay setTimeout(() => { console.log('Sending remaining request headers'); const request = [ 'Host: 127.0.0.1', 'Connection: keep-alive', '', '' ].join('\r\n'); client.write(request); }, 10000); }); client.on('data', (data) => { console.log(`Received: ${data}`); client.destroy(); // Kill client after server's response }); client.on('close', () => { console.log('Connection closed'); }); client.on('error', (err) => { console.error(`Error: ${err.message}`); });
- When
github-actions commented
on Jun 27, 2026 on Jun 27, 2026 – with GitHub ActionsContributorMore actionsThis issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.- addedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Jun 27, 2026 github-actions commented
on Jul 28, 2026 on Jul 28, 2026 – with GitHub ActionsContributorMore actionsThis issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
Metadata
Metadata
Assignees
Labels
httpIssues and PRs related to the http subsystem.Issues and PRs related to the http subsystem.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
In case timeout is reached for
server.headersTimeout, node keeps the socket open until it receives data orserver.timeoutis reached.I believe this issue causes dropped connections / 502 errors on AWS ALB (load balancer), because it tries to send data and socket closes immediately after data is received.
I have set
server.headersTimeout = 10 * 1000and ran tcpdump to confirm.As you can see in the dump, 24 seconds has passed, data was received, acknowledged and socket closed after data was received.
I expected socket to be closed after 10 seconds has passed without data.