doc: clarify HTTP/1.1 response ordering

Author: mcollina

SECURITY.md

@@ -276,6 +276,16 @@ the community they pose.
 
 ### Examples of non-vulnerabilities
 
+#### Malicious protocol peers
+
+* Node.js treats data from remote network peers as untrusted, and bugs in
+  parsers or protocol implementations may be security vulnerabilities.
+* Node.js may close HTTP/1.1 keep-alive connections when data is detected while
+  no request is outstanding, as described by RFC 9112 section 9.2. Reports that
+  rely solely on a malicious or compromised server racing unsolicited or
+  misordered responses within the same HTTP/1.1 connection reuse lifecycle are
+  generally not considered Node.js vulnerabilities.
+
 #### Malicious Third-Party Modules (CWE-1357)
 
 * Code is trusted by Node.js. Therefore any scenario that requires a malicious

doc/api/http.md

@@ -70,6 +70,14 @@ over the same connection, in which case the connection will have to be
 remade for every request and cannot be pooled. The `Agent` will still make
 the requests to that server, but each one will occur over a new connection.
 
+### Response ordering with connection reuse
+
+On a reused HTTP/1.1 keep-alive connection, responses are associated with
+requests by their order on that connection. HTTP/1.1 keep-alive does not provide
+per-request response attribution beyond that ordering. Applications that require
+per-request connection isolation can use a separate `Agent`, disable keep-alive,
+or pass `agent: false`.
+
 When a connection is closed by the client or the server, it is removed
 from the pool. Any unused sockets in the pool will be unrefed so as not
 to keep the Node.js process running when there are no outstanding requests.
@@ -109,6 +117,8 @@ http.get({
 });
 ```
 
+Use `agent: false` to avoid connection reuse for a request.
+
 ### `new Agent([options])`
 
 <!-- YAML