René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"proposal: add req.signal (AbortSignal) for automatic client disconnect detection","articleBody":"### What is the problem this feature will solve?\n\nCurrently, when we handle HTTP requests with async operations (such as DB queries or fetch calls), there isn't a straightforward way to cancel pending work if a client disconnects. The common workaround is to manually wire up `req.on('close')` or check `req.destroyed`:\n\n```js\nserver.on('request', async (req, res) => {\n  const ac = new AbortController();\n  req.on('close', () => ac.abort());\n\n  const data = await fetch('https://slow-api.com', { signal: ac.signal });\n  res.end(JSON.stringify(data));\n});\n```\n\nThis is boilerplate that every server framework ends up reimplementing.\n\nDesign considerations\n\nLazy initialization `AbortController` only created when `req.signal` is accessed (zero overhead for code that doesn't use it)\nSocket close = abort no conditional logic, signal aborts whenever the socket closes\n`_destroy` integration `req.destroy()` also triggers abort\n`configurable: true` allows framework override\nHTTP/2 parity `Http2ServerRequest` should eventually get the same property (follow-up)\n\nPrior art\n\nWeb Fetch API: `Request.signal`\nDeno: `request.signal` on `Deno.serve()` handler\n\n@nodejs/http @nodejs/http2 \n\n\n### What is the feature you are proposing to solve the problem?\n\nadd a lazy `signal` getter to `IncomingMessage` that returns an `AbortSignal` which aborts when the underlying socket closes:\n\n```js\nserver.on('request', async (req, res) => {\n  const data = await fetch('https://slow-api.com', { signal: req.signal });\n  res.end(JSON.stringify(data));\n});\n```\n\n### What alternatives have you considered?\n\n_No response_","author":{"url":"https://github.com/mertcanaltin","@type":"Person","name":"mertcanaltin"},"datePublished":"2026-03-28T20:32:45Z","url":"https://github.com/nodejs/node/issues/62481"}