[robobun]

Problem

• A response without a body (304, HEAD) can leave open a connection marked to close by Connection: close, HTTP/1.0 or server.stop(). The client gets no FIN until idleTimeout.
• uws_res_end_without_body (src/uws_sys/libuwsockets.cpp) marks the response done and runs no uncork and no close gate. HttpResponse::cork() skips its own gate when another socket's cork() flushed the response's slot (HttpResponse.h:968), and callers outside cork() have none.

Fix

• The shim completes through finishResponseInCorkBuffer(0), the uncork and close gate internalEnd() ends on.
• node:http res.destroy() drops corked bytes and closes the socket itself. It moves to uws_res_abandon, the shim's old behaviour.
• Verified: bun-server.test.ts (7 cases), bun-serve-html.test.ts (2), serve.test.ts, node-http-req-complete.test.ts. Suites are in Notes.

Background

• uWS batches a socket's writes in one of two cork slots per loop. A third cork() flushes the oldest.
• The close gate closes a connection once its response is complete, marked to close and fully sent.
• Considered a gate at cork()'s lost-slot return (uws: run the close gate in HttpResponse::cork() when the cork slot was lost #37446): every post-await response with a body exits there, and ends outside cork() stay ungated.

Downsides

• uws_res_end_without_body can close the socket before it returns, as end() does. http: consolidate the open fetch, Bun.serve, node:http, node:http2 and HTTP/3 pull requests #46528 keeps the shim's "No close gate here" note.
• A static HEAD or 304 executes 110 instructions to end, was 59. A JS-produced one before static responses in a pipelined read takes 5 TCP segments, was 3.
• .text of the uWS unit: +700 bytes.

Notes

Reported by a maintainer in review of #37074: "HttpResponse::cork() early return skips the close gate ... a completed Connection: close / HTTP/1.0 response on a non-parsing socket is never shut".

Repro of the reported order. An async handler answers a Connection: close POST whose body never arrives:

req.text().catch(() => {
  wsA.cork(() => {
    wsA.send("a");
    wsB.cork(() => wsB.send("b")); // both cork slots hold data: this flushes the response's slot
  });
});
await Bun.sleep(0);
return new Response(null, { status: 304 });

The client receives HTTP/1.1 304 Not Modified and no FIN. Ending the response rejects the unread body, and the microtasks that run then execute while the response still holds its cork slot. No cork() call is needed: four such requests that complete in one microtask drain leave two connections open, because each response completes inside the drain of the one before it.

Callers outside cork(). The request that waited for the bundle of an HTML import is answered from an event-loop task. After 500 Build Failed (production build failed) and after the dev server's 405, the client gets no FIN on main, with no other socket involved.

Also in the diff

• RequestContext::end_without_body no longer calls close_if_done_and_marked(). That shim stays for the sendfile end.
• The comments in HTMLBundle.rs and dev_server/deferred_request.rs that said this end cannot close the socket are gone.

Why not the gate at cork()'s lost-slot return

• A response with a body that follows an await ends through internalEnd(), which uncorks. cork() then takes the lost-slot return. A gate there runs for every such response.
• Since WebSocket: real closing handshake, one failure path, ws rewritten on native transports (consolidates the open WebSocket PRs) #45223 server.upgrade() runs inside resp.corked and uWS adopts the socket in place. At that return this can be a live WebSocket, so uws: run the close gate in HttpResponse::cork() when the cork slot was lost #37446 as written would read a WebSocket as an HttpResponseData.
• The two HTML import ends and the other raw ends do not run inside cork().

Question for a maintainer. Is it acceptable that uws_res_end_without_body closes the socket before it returns? The note said callers keep using the response. Today the callers either return or call clear_aborted / clear_on_writable / clear_timeout, which are no-ops on a closed socket because end() and tryEnd() already close in-call. If the end has to stay non-closing, the alternative is to make uws_res_close_if_done_and_marked uncork (as #41341 does) and to add a gate call at each raw end outside the parser.

Tests

• bun-server.test.ts, "a response without a body closes a connection that is marked to close": request Connection: close, HTTP/1.0, response Connection: close, server.stop() in flight, TLS, and the two eviction orders (two corked WebSockets, two streaming responses). All 7 time out on main.
• bun-serve-html.test.ts: the two HTML import cases above. Both time out on main.
• serve.test.ts, "share one send() until a handler runs JavaScript": new rows for responses without a body. On main mixedHead is 3 segments. fetchHead 8, staticHead 1, fetch304 8 and static304 1 are the same before and after.
• node-http-req-complete.test.ts, "res.destroy() drops the chunk that res.write() queued in the same turn": passes on main, under Node v26.3.0 and with this change. It fails (the client receives the dropped chunk) when uws_res_abandon is made to gate, and no existing test did.

Measurements

• Instruction counts are path counts from llvm-objdump -d of src/uws_sys/libuwsockets.cpp compiled with the release flags and without LTO, TCP arm, over uws_res_end_without_body, finishResponseInCorkBuffer and uncorkCompletedResponse (calls to the one-line usockets accessors not included: 7 on main, 14 here). The 110 is what an end with a body already pays at completion. perf, valgrind, strace and bloaty are not installed in the build container, so there is no dynamic count and no pair of full release builds.
• In that object 550 of 551 functions are instruction-identical, among them HttpResponse::cork(), internalEnd(), uws_res_end, uws_res_try_end, uws_res_end_stream, uws_res_cork and HttpContext::onData. uws_res_end_without_body goes from 450 to 264 bytes. New: uws_res_abandon (488 bytes) and two out-of-line finishResponseInCorkBuffer instantiations (199 bytes each, which the NodeHTTP.cpp unit already has).
• Segments are counted with getsockopt(TCP_INFO) in the test above.
• Reads after an in-call close: a local build poisoned (ASAN) the response ext of every socket that the bodyless end closed. 31 such closes across the suites below, 0 reads of a poisoned ext.

Suites run on the debug build: bun-server, serve, bun-serve-html, bun-serve-static, bun-serve-file, bun-serve-routes, serve-directory-routes, request-smuggling, websocket-server, node-http, node-http-req-complete, node-http-server-abort-events, node-http-closed-response, node-http-server-close-drain, node-http-upgrade-body, test/bake/dev/html, test/bake/dev/plugins, test/bake/serve-plugins-dev-server. Failures that also occur without this change: the privileged port test (the container runs as root), one stack-shape assertion in node-http-closed-response on debug builds, and timeouts of subprocess-heavy tests under the debug build that pass alone.

Not changed here

• uws_res_end_sendfile still completes without gating and keeps its caller-side uws_res_close_if_done_and_marked.
• The gate at cork()'s tail and the one at HttpContext::onData's tail stay as they are.
• uws_res_abandon keeps the header writes the shim made, so res.destroy() puts the same bytes on the wire as on main. node:http: send nothing on destroy() before the headers go out, and a 500 (not an empty 200) for a throwing listener #39366 and http: consolidate the open fetch, Bun.serve, node:http, node:http2 and HTTP/3 pull requests #46528 each add a uws_res_abandon for the same caller that drops them. If one of them lands first, this PR takes that shim and changes only uws_res_end_without_body.

Earlier attempts: #35555 (the end shims gate themselves) and #37446 (gate at cork()'s tail, the source of the two eviction tests).

[robobun]

^{Updated 11:44 AM PT - Nov 10th, 2026}

✅ @robobun, your commit 76f3a768876351845b2f157143c85dfb2771e9bf passed in Build #139804! 🎉

---

🧪   To try this PR locally:

bunx bun-pr 48486

That installs a local version of the PR into your bun-48486 executable, so you can run:

bun-48486 --bun

[robobun]

Status

How it was reproduced, on main (89452d2) and on canary 1.4.3:

• A Bun.serve async handler answers a Connection: close POST, whose body never arrives, with a 304. While the response completes, two corked WebSockets (or two streaming responses) take its cork slot. The client receives HTTP/1.1 304 Not Modified and no FIN until idleTimeout.
• Four such requests that complete together leave two connections open, with no cork() call in user code.
• The request that waited for an HTML import's bundle gets 500 Build Failed (production build failed) or the dev server's 405, and no FIN.

With this PR each connection closes right after the response. The tests are in test/js/bun/http/bun-server.test.ts, test/js/bun/http/bun-serve-html.test.ts and test/js/bun/http/serve.test.ts.

PR: #48486. It replaces #37446, which a stale sweep closed.