http: emit aborted event on requests

doc/api/http.md

@@ -2787,9 +2787,23 @@ deprecated:
   - v16.12.0
 -->
 
-> Stability: 0 - Deprecated. Listen for `'close'` event instead.
+> Stability: 0 - Deprecated. Use the `'close'` event on the response. If it was aborted `writableFinished` will be false.
 
-Emitted when the request has been aborted.
+Emitted when the request has been aborted, i.e. the underlying connection
+was terminated before the message (request or response) was fully
+received *and* before the message cycle completed (for a server request,
+before the corresponding response was finished).
+
+This event is only emitted if the message was not already fully
+processed. In particular, note that:
+
+* `'aborted'` is not emitted after the `'close'` event has already fired for
+  a message that completed normally.
+* Fully reading the body of an `http.IncomingMessage` (for example via
+  `req.resume()` or by piping/consuming it) does **not** by itself mean the
+  request/response cycle is done. On the server, a request can still be
+  aborted (its `'aborted'` event fired) after its body has been completely
+  read, as long as the corresponding response has not finished yet.
 
 ### Event: `'close'`
 
@@ -2804,6 +2818,18 @@ changes:
 
 Emitted when the request has been completed.
 
+More precisely, this event is emitted when this side of the HTTP message
+(headers and body) has finished being processed, either because it was
+fully read (`'end'` was emitted) or because the message stream was
+destroyed.
+
+`'close'` does **not** imply that the request/response cycle as a whole
+finished successfully, and it does **not** imply that the peer received a
+complete response. For example, on the server side `'close'` on the
+`request` object can fire as soon as the request body has been read, well
+before `response.end()` has been called or the response has actually been
+sent to the client.
+
 ### `message.aborted`
 
 <!-- YAML
@@ -2831,6 +2857,7 @@ added: v0.3.0
 The `message.complete` property will be `true` if a complete HTTP message has
 been received and successfully parsed.
 
+
 This property is particularly useful as a means of determining if a client or
 server fully transmitted a message before a connection was terminated:
 

lib/_http_incoming.js

@@ -231,7 +231,11 @@ IncomingMessage.prototype._read = function _read() {
 // any messages, before ever calling this.  In that case, just skip
 // it, since something else is destroying this connection anyway.
 IncomingMessage.prototype._destroy = function _destroy(err, cb) {
-  if (!this.readableEnded || !this.complete) {
+  // `this.aborted` may already have been set to `true` by the caller
+  // (e.g. abortIncoming() in _http_server.js) to indicate that the
+  // connection went away while the request/response was still pending.
+  // Avoid clobbering that and emitting a duplicate 'aborted' event.
+  if (!this.aborted && (!this.readableEnded || !this.complete)) {
     this.aborted = true;
     this.emit('aborted');
   }

lib/_http_server.js

@@ -909,6 +909,18 @@ function socketOnClose(socket, state) {
 function abortIncoming(incoming) {
   while (incoming.length) {
     const req = incoming.shift();
+    // Any request still sitting in `state.incoming` has not had its
+    // response finished yet (see resOnFinish(), which shift()s the
+    // request off this array once the response completes). If the
+    // underlying socket is going away while the request is still
+    // pending here, that unambiguously means the client (or the
+    // connection) went away before the request/response cycle could
+    // complete, i.e. the request was aborted - regardless of whether
+    // the request body itself had already been fully read.
+    if (!req.aborted) {
+      req.aborted = true;
+      req.emit('aborted');
+    }
     req.destroy(new ConnResetException('aborted'));
   }
 }

test/parallel/test-http-server-aborted-after-request-end.js

@@ -0,0 +1,53 @@
+'use strict';
+
+// Regression test: the request object's 'aborted' event (and .aborted
+// property) must still be emitted/set when the client destroys the
+// connection, even if the request body had already been fully consumed
+// (i.e. the request stream already emitted 'end') before the response
+// finished. This complements test-http-server-aborted-while-reading-body.js,
+// which covers aborting *while* the body is still being read.
+// See https://github.com/nodejs/node/issues/40775.
+
+const common = require('../common');
+const assert = require('assert');
+const http = require('http');
+
+let clientReq;
+const server = http.createServer(common.mustCall((req, res) => {
+  // Close the server once the request stream is torn down, regardless of
+  // whether 'aborted' fired. This is guaranteed to happen (unlike
+  // 'aborted', which is exactly what's under test here), so a regression
+  // makes this test fail fast via the mustCall() check below instead of
+  // hanging forever.
+  req.on('close', common.mustCall(() => {
+    server.close();
+  }));
+
+  req.on('aborted', common.mustCall(() => {
+    assert.strictEqual(req.aborted, true);
+  }));
+
+  req.on('end', common.mustCall(() => {
+    // At this point the request body has been fully read, but the
+    // response has not been sent yet. Destroying the client request
+    // now must still result in the server's 'aborted' event firing.
+    clientReq.destroy();
+  }));
+
+  req.resume();
+}));
+
+server.listen(0, common.mustCall(() => {
+  clientReq = http.request({
+    method: 'POST',
+    port: server.address().port,
+    headers: { connection: 'keep-alive' },
+  }, common.mustNotCall());
+
+  // Destroying the request may or may not surface an error on the client
+  // side depending on timing; only the server-side 'aborted' event
+  // (asserted above) is under test here.
+  clientReq.on('error', () => {});
+
+  clientReq.end();
+}));

test/parallel/test-http-server-aborted-while-reading-body.js

@@ -0,0 +1,55 @@
+'use strict';
+
+// Regression test: the request object's 'aborted' event (and .aborted
+// property) must be emitted when the client destroys the connection while
+// the server is still in the middle of reading the request body, i.e.
+// before 'end' has fired on the request stream. This is the "classic"
+// abort case and complements
+// test-http-server-aborted-after-request-end.js, which covers aborting
+// *after* the body has already been fully read.
+// See https://github.com/nodejs/node/issues/40775.
+
+const common = require('../common');
+const assert = require('assert');
+const http = require('http');
+
+let clientReq;
+const server = http.createServer(common.mustCall((req, res) => {
+  // Close the server once the request stream is torn down, regardless of
+  // whether 'aborted' fired. This is guaranteed to happen (unlike
+  // 'aborted', which is exactly what's under test here), so a regression
+  // makes this test fail fast via the mustCall() check below instead of
+  // hanging forever.
+  req.on('close', common.mustCall(() => {
+    server.close();
+  }));
+
+  req.on('aborted', common.mustCall(() => {
+    assert.strictEqual(req.aborted, true);
+    assert.strictEqual(req.complete, false);
+  }));
+
+  req.on('data', common.mustCall(() => {
+    // Once the first chunk of the body has arrived, destroy the client
+    // connection before it finishes sending the rest of the body (and
+    // before the server ever calls res.end()/sends a response).
+    clientReq.destroy();
+  }));
+}));
+
+server.listen(0, common.mustCall(() => {
+  clientReq = http.request({
+    method: 'POST',
+    port: server.address().port,
+    headers: { connection: 'keep-alive' },
+  }, common.mustNotCall());
+
+  // Destroying the request may or may not surface an error on the client
+  // side depending on timing; only the server-side 'aborted' event
+  // (asserted above) is under test here.
+  clientReq.on('error', () => {});
+
+  // Write a chunk but never call end(), so the server never sees the body
+  // finish before the connection is destroyed.
+  clientReq.write('some data');
+}));