René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"http: Server.closeIdleConnections() does not iterate pre-request sockets","articleBody":"### Version\n\nv24.15.0 (also tested on several other versions)\n\n### Platform\n\n```text\nDarwin G0674 25.4.0 Darwin Kernel Version 25.4.0: Thu Mar 19 19:30:44 PDT 2026; root:xnu-12377.101.15~1/RELEASE_ARM64_T6000 arm64\n\n(Also tested on Linux Mint)\n```\n\n### Subsystem\n\nhttp\n\n### What steps will reproduce the bug?\n\n```js\nimport { createServer } from \"node:http\";\nimport { createConnection } from \"node:net\";\n\nconst server = createServer((req, res) =\u003e res.end(\"ok\"));\nserver.listen(3099, \"127.0.0.1\");\nawait new Promise((r) =\u003e server.once(\"listening\", r));\n\n// TCP socket that doesn't send anything\nconst sock = createConnection(3099, \"127.0.0.1\");\nawait new Promise((r) =\u003e sock.once(\"connect\", r));\n\n// Wait until the server has actually accepted and registered the socket,\nawait new Promise((r) =\u003e server.once(\"connection\", r));\n\nconst closed = new Promise((r) =\u003e\n  server.close(() =\u003e r(performance.now())),\n);\nconst closeStart = performance.now();\nserver.closeIdleConnections();\n\nconsole.log(\"after closeIdleConnections, awaiting close...\");\nconst t = await Promise.race([\n  closed,\n  new Promise((r) =\u003e setTimeout(() =\u003e r(null), 2000)),\n]);\nconsole.log(t === null ? \"still hung after 2s\" : `closed in ${t - closeStart}ms`);\n\nsock.destroy();\n```\n\n### How often does it reproduce? Is there a required condition?\n\nNone.\n\n### What is the expected behavior? Why is that the expected behavior?\n\n[Server.closeIdleConnections() docs](https://nodejs.org/api/http.html#serverclose-idle-connections) say:\n\n\u003e Closes all connections connected to this server which are not sending a request or waiting for a response.\n\nA TCP socket that is connected but has not yet sent any HTTP data fits the description to me. So the expected behavior would be `closeIdleConnections()` to close them:\n\n```\nafter closeIdleConnections, awaiting close...\nclosed in \u003csome number below 2000\u003ems\n```\n\n### What do you see instead?\n\nBut pre-request sockets are not closed:\n\n```\nafter closeIdleConnections, awaiting close...\nstill hung after 2s\n```\n\n\n### Additional information\n\nBrowsers (Chrome especially) routinely open speculative TCP connections that don't send HTTP data until needed. They remain open for a while even when the user closes the tab or navigates away from the page. Server-side, those sockets are open with `bytesRead === 0` and they block graceful shutdown in pretty much all frameworks with a graceful shutdown feature:\n\n- `server.close()` waits for them (as it should).\n- `server.closeIdleConnections()` is the documented escape hatch for \"drop idle connections now,\" but per above it doesn't.\n- The only working option is `server.closeAllConnections()`, which also kills in-flight requests and defeats the purpose of graceful drain.\n\nA quick search shows that it affects graceful shutdown in frameworks. See, for instance, [Fastify #5713](https://github.com/fastify/fastify/issues/5713) (closed as \"not planned\").\n\nA user-space workaround exists (track `'connection'` events, drop sockets with `bytesRead === 0`) but there's at least a mismatch between the docs and the impl.\n\nThe root cause seems to be the implementation in [`lib/_http_server.js`](https://github.com/nodejs/node/blob/main/lib/_http_server.js) that iterates `this[kConnections].idle()`:\n\n```js\nServer.prototype.closeIdleConnections = function closeIdleConnections() {\n  if (!this[kConnections]) return;\n  const connections = this[kConnections].idle();\n  for (let i = 0, l = connections.length; i \u003c l; i++) {\n    if (connections[i].socket._httpMessage \u0026\u0026 !connections[i].socket._httpMessage.finished) continue;\n    connections[i].socket.destroy();\n  }\n};\n```\n\n`kConnections` is HTTP-level state; sockets are added when an HTTP exchange begins. Pre-request sockets exist in `net.Server`'s connection list (`server._connections`) but never reach `kConnections`. So the HTTP-level bookkeeping doesn't see them at all.\n\nIt would be nice to see a proper Node.js-level fix, or, if it's not possible or desirable for whatever reason, a documentation update to warn against the caveat.","author":{"url":"https://github.com/cyco130","@type":"Person","name":"cyco130"},"datePublished":"2026-05-20T10:21:22.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/63452/node/issues/63452"}