proposal: add req.signal (AbortSignal) for automatic client disconnect detection #62481
Description
What is the problem this feature will solve?
Currently, 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:
server.on('request', async (req, res) => {
const ac = new AbortController();
req.on('close', () => ac.abort());
const data = await fetch('https://slow-api.com', { signal: ac.signal });
res.end(JSON.stringify(data));
});This is boilerplate that every server framework ends up reimplementing.
Design considerations
Lazy initialization AbortController only created when req.signal is accessed (zero overhead for code that doesn't use it)
Socket close = abort no conditional logic, signal aborts whenever the socket closes
_destroy integration req.destroy() also triggers abort
configurable: true allows framework override
HTTP/2 parity Http2ServerRequest should eventually get the same property (follow-up)
Prior art
Web Fetch API: Request.signal
Deno: request.signal on Deno.serve() handler
@nodejs/http @nodejs/http2
What is the feature you are proposing to solve the problem?
add a lazy signal getter to IncomingMessage that returns an AbortSignal which aborts when the underlying socket closes:
server.on('request', async (req, res) => {
const data = await fetch('https://slow-api.com', { signal: req.signal });
res.end(JSON.stringify(data));
});What alternatives have you considered?
No response