#44217 node:http: the server socket grants the connection to one response and takes it back

Repro (from the report; bun repro.mjs printed a segfault on 1.4.0 to 1.4.3, returned on 1.3.14 and Node.js v26.3.0):

import http from "node:http";
import net from "node:net";
let n = 0;
const server = http.createServer((req, res) => {
  if (n++ > 0) return;
  res.detachSocket(req.socket);
  setTimeout(() => { res.end("late"); console.log("returned"); server.close(); server.closeAllConnections(); }, 100);
});
server.listen(0, "127.0.0.1", () => {
  const c = net.connect(server.address().port, "127.0.0.1", () => {
    c.write("GET /a HTTP/1.1\r\nHost: t\r\n\r\n");
    c.write("GET /b HTTP/1.1\r\nHost: t\r\n\r\n");
    setTimeout(() => c.destroy(), 30);
  });
  c.on("error", () => {}); c.resume();
});

Commits. The first commit changes no behaviour: raw_response moves into a private module behind writer() / reader(), and currentResponseObject becomes private behind currentResponse() / setCurrentResponse(). The release build of that commit alone, on its earlier base 1313ca61d4, had the .text size of that base (58,143,989 bytes) and the same instruction count in every NodeHTTPResponse function. The second commit is the role and the take-back. The third is the WebSocket case.

States of a response that is replaced.

A taken-back response gets SOCKET_CLOSED, so is_done(), the Drop assertion and the JS checks of handle.flags need no change. JS gets no event for it.

Label of each site (NodeHTTPResponse.rs unless a file is named; 25 writer, 19 reader, 4 release, 1 take_for_upgrade):

Measurements. Release builds of main (9f70da0741) and of this PR, linux x64. perf is not permitted in the container (perf_event_paranoid is 4) and valgrind cannot be installed, so there is no dynamic instruction count.

Tests. Each test spawns one fixture process that runs the scenarios of one suite. A fixture that finds a response with its refs still held exits with code 1, so an unfixed build fails in seconds.

• 4 triggers x 11 later uses x 2 read orders (second request in the same read, or in a later one), on TCP and TLS.
• A finished response that the next keep-alive request replaced: 11 calls on its native handle after the close.
• The client stays: response 2 and 3 arrive in order, response 1 cannot write, and the socket does not take response 1 again.
• A queued response calls its native handle: nothing reaches the wire before its turn. Without the CURRENT check this test fails.
• A replaced response with an 8 MB write in the socket buffer: the bytes go out before response 2, and the process exits after a GC.
• A response that native code completed is replaced: the process exits.
• A WebSocket adopts the connection with a response queued, on TCP and TLS. The scenarios run side by side. In that form main shows no sanitizer report on TCP or on TLS, and the test fails on main only through the check of the held refs. When the TCP scenarios run one after the other, main reports heap-buffer-overflow in uWS::HttpContextData::isParsing.
• main (9f70da0741), debug+ASAN: 0 pass, 20 fail. Release 1.4.3: 0 pass, 20 fail.
• The tests are in a new file. node-http-uaf.test.ts runs two fixtures that loop thousands of requests and are close to their time limits on debug and ASAN builds. The 20 fixture processes of this file would compete with them for the CPU.
• The time limit in the test file applies only to a local debug or ASAN build, which needs about 4 s to start one fixture. CI uses the time of its runner.

Still different from Node.js after a replacement. Not changed here.

• Node.js buffers the writes of a detached response until assignSocket(). Bun drops them. write() returns false, end() emits 'prefinish'.
• Node.js ignores a 'close' event that user code emits on a response. Bun's dispatcher takes it as the end of the response.
• Node.js aborts the request of a replaced response at the close (abortIncoming). Bun emits nothing for it.
• Node.js does not dispatch a request that follows an Upgrade request in the same read. Bun queues it. When the second request arrives in a later read, Node.js queues it too.

Found, not fixed here.

• res.writeContinue() and res.addTrailers() of a response that lost the connection go through the socket's current response and reach the wire in its place. res._send() on a queued response has no queue check.
• After res.emit('close') on an open response whose handler returned, native code ends the response with a bare \r\n.
• A 'request' listener that throws makes the process segfault when its response waits behind a raw socket.write() from a 'connection' listener. mark_dispatch_threw_if_queued() compares against the current-response slot of the socket, and that slot is empty there. main has this since #43557. It is not in a release.
• A response that upgrades while a large write() still holds a tail by reference drops that tail. main does the same.

Same as Node.js. A request that is queued behind a request that takes the socket for a WebSocket gets no event at the takeover. It gets 'aborted', 'error' and 'close' when the socket closes. Node.js v26.3.0 does the same when the second request arrives in a later read (an Upgrade request that a 'request' listener holds and then answers with a raw 101). An earlier version of this description listed this as a defect, and a review reply said that Node.js does not reach this state. Both were wrong.

Self-review. Two reviews ran. The first covered the first two commits. Its verdict asked for three changes, and all three are here: one PR that has the tests, the WebSocket case, and no statement about Node.js in the tests that was not checked. The second covered the merged diff and finished after the merge. It raised 18 concerns (11 to fix, 7 to consider). This PR addresses none of them. The ones that change code, tests or this text:

• The crash and the writeContinue() / addTrailers() item in the list above.
• No test scenario has a request body, and req.destroy() on a queued request has no test.
• The draining scenario still passes when the call that clears the handlers is removed. I confirmed that with a copy of the debug binary that has a no-op in the place of that call.
• The WebSocket scenarios fail on main only through a private flag bit (see Tests).
• Wrong text in this description: the statement about Node.js, the label counts, and the note about the WebSocket test. They are corrected above.

Question for a maintainer. The response keeps its pointer and a CURRENT bit, and the socket pushes a take-back. The other form removes the pointer and asks the socket on each use: about 15 more loads per request, and the wrapper grows from 64 to 80 bytes. This PR builds the first.

Platforms. I ran the tests on Linux x64. CI ran the new test file on macOS and Windows, x64 and aarch64: 20 pass on each.