tls: consolidate the open TLS fixes (both engines, node:tls, node:https, WebSocket, SQL) by Jarred-Sumner · Pull Request #44618 · oven-sh/bun

Jarred-Sumner · 2026-10-06T06:16:43Z

What does this PR do?

Consolidates the open TLS pull requests into one. Each was reproduced on main and, for node:* behavior, on Node v26.3.0 first. About a third are ported as written, the rest are rewritten smaller or merged into one fix where several PRs patched the same cause. One commit per fix, so it can be read commit by commit.

Fixes #43520, fixes #31396, fixes #43635, fixes #37193, fixes #43846, fixes #17932, fixes #41061, fixes #36887, fixes #31810, fixes #35240, fixes #32234, fixes #44365, fixes #43807, fixes #42280, fixes #44517.
Addresses #41856 (SNI and servername; not checkServerIdentity for SQL), #24845 (the spin is gone, shown with fault injection on Linux; not run on macOS), #19754 (node-fetch forwards the agent's TLS options; the Kubernetes client itself was not run).

The ones that matter most

	On `main`	PRs
Client certificate disclosure	`https.request()` with a client certificate sends it to a server it then refuses (wrong name, `checkServerIdentity`, `destroy()` in `'secureConnect'`, `terminate()` in `handshake`). A server can force it with a junk record behind its Finished	#43946
False `authorized`	Over a Duplex, `secureConnect` with `authorized === true` for a peer that failed the key proof; `secureConnect` for a plaintext peer with `rejectUnauthorized: false`	#44422, #32929
Cleartext https	`https.createServer()` without a usable key/cert answers plain HTTP	#41672, #33539
Revoked client certificates	An https mTLS server never sees `crl`, so a revoked client is `authorized`	#41641
Pooled sockets	Requests with different client certificates or CAs share an `https.Agent` socket and session	#42498
Silent plaintext	`tls: [...]` given to `Bun.listen` / `Bun.connect` is plain TCP	#41490
Server weakened by a client knob	`NODE_TLS_REJECT_UNAUTHORIZED=0` turns off a server's client-certificate enforcement	#35245
Pins never checked	`WebSocket` never calls `tls.checkServerIdentity` and ignores `tls.serverName`	#41648
`verify-full` dropped	`PGSSLMODE=verify-` is lost next to a `TLS_` URL variable; `tls: true` sends no SNI	#44498
Crashes	use-after-free from `destroy()` in `ALPNCallback` over a Duplex; `abort()` on a late `setSession()`; SIGABRT in `fetch` with an https proxy from the environment and a `Bun.file()` body	#44462, #41671, #44458
Stream corruption	A TLS `write()` can lose 16 KiB it reported as written while another socket on the loop is stalled	#44529
Hangs and spins	100% CPU on a failing `send()`; a fatal `SSL_write` leaves the socket open forever; `idleTimeout` never sheds a TLS client that ignores `close_notify`	#34510, #38176, #42336
Wrong certificate (regression since 1.3.14)	Connections accepted before `stop()` / `close()` get the default certificate and skip their entry's `requestCert` / `ca`	#42355
Quadratic Duplex / proxy tunnel	Reading one chunk over a Duplex, CPU: 8 MB 0.88 s → 0.14 s, 16 MB 3.18 s → 0.23 s, 32 MB 11.75 s → 0.39 s; `fetch` upload through CONNECT: 1.7 s → 0.18 s (debug build)	#44464

By area

fd engine, write path (openssl.c, socket.c): usockets: resume a paused TLS socket when its graceful close waits for the peer #42352, usockets: close a TLS socket whose send() keeps failing instead of spinning the writable dispatch #34510 + tls: close the connection when a post-handshake SSL_write fails instead of leaving it open #38176 + tls: report a rejected send() as a write error instead of a clean close #42336 as one change, tls: queue unsent ciphertext per connection so write() counts every sealed record #44529, fetch: send a Bun.file() body over TLS and CONNECT tunnels in bounded chunks #44458, Bun.connect, Bun.listen: document when a TLS socket closes with no handshake call #44192. A rejected send() ends the write side only and closes at the next writable event unless the peer's bytes are still queued (a 413 sent before a reset is still read). No new per-socket state. Also, on kqueue, a FIN no longer ends a socket that waits in the low-priority queue (loop.c): with more than 5 TLS handshakes at once, a client that ended right after its handshake could be reset and its server socket report socket hang up, because the eof that the sentinel read knote reports was acted on ahead of the unread Finished. That is on main too (the macOS entry for node-tls-server.test.ts in test/flaky-tests.txt: 7 of 48 recent builds of other branches), and this branch made it likelier (6 of 8 builds), since Finished now leaves in one segment with the close_notify.
Error reporting, both engines: node:tls: a handshake that did not complete is never an established session #44422, node:tls: report the fatal TLS alert when a handshake over a Duplex fails #32929, tls: report a first handshake that the peer ends with close_notify (Duplex, named pipe, proxy tunnel) #44516, tls: fix renegotiation leaving the handshake state latched (lost drain, bogus ECONNRESET on close) #37094, tls: report a fatal TLS error that arrives after the handshake #41272 + tls: report a fatal post-handshake SSL error over a Duplex or a named pipe #42324 + tls: report a refused renegotiation as a protocol failure, not as a certificate verdict #44223 as one change, tls: report a handshake that the peer left, and reset the chain check for a renegotiation #44021, tls: deliver parked sessions before the data decrypted with them on the duplex path #37472, node:tls: destroy() in the handshake callback releases the held final flight #43946, node:tls: abort handshake with fatal alert when server rejects client cert #33630. One channel: a fatal error on an established session is reported, then the engine closes the connection itself, whatever the owner does with the report. test/js/bun/net/tls-fatal-error-closes.test.ts asserts closed-and-nothing-delivered for every owner (node:tls, Bun.connect, Bun.listen, fetch direct and through CONNECT, Bun.serve, WebSocket direct and through a proxy, Postgres, MySQL, Valkey, Duplex).
Duplex engine (SSLWrapper, UpgradedDuplex): tls: free a stream TLS engine's SSL after its handshake pass has returned #44462, node:http2: keep frames whole and sent once over a TLS socket that wraps a Duplex #43529, tls: pause and resume a wrapped Duplex transport with the TLS socket's reads #42332, tls: give SSLWrapper its own queue-backed BIO instead of two BIO_s_mem #44464. node:tls: complete write(cb) and end(cb) over a Duplex when the stream completes the ciphertext #43877 + tls: ignore a 'drain' that a Duplex transport emits from inside its own write() #44394 were in and are out again, see "Worth a look" 5.
node:tls wrap lifecycle (net.ts, tls.ts): node:tls: attach the onConnectEnd 'end' listener once per connect() #38007, node:net: emit 'close' on a server TLS wrap whose handshake fails on the stream-level engine #38058, node:tls: destroy the wrapped net.Socket when a TLS wrap is destroyed #38028 + node:tls: report a wrapped socket's connect failure on the TLSSocket #38122 + node:tls: use the stream engine for server-side wraps the native upgrade cannot adopt #38076 as one change (six copies of the attach code become two helpers), node:tls: keep the handle attached while a client handshake protocol failure is reported #38311, node:tls: let connect() re-dial a TLSSocket whose connection is still open #39008, node:http2: destroy the accepted socket when an injected connection's TLS proxy is destroyed #38154, node:tls: emit 'connect' on a TLSSocket that wraps a connecting socket #42340 + node:tls: clear connecting on a TLSSocket that wraps a connected socket #42343 + node:tls: send the FIN when end() runs before the TLS handle is attached #42339 + node:net: send the FIN when end() on a socket runs around its TLS wrap #42453 as one change, node:tls: report a net.Socket transport's error on the TLS socket #43791, node:tls: ignore onread when the TLS socket wraps an existing socket #42425, node:tls: call checkServerIdentity with the connect options as this #44085, node:tls: run a server-side TLSSocket's own ALPNCallback when socket.server is set #42683, node:tls: report servername as false on server sockets when the client sent no SNI #39088, node:tls: honor setServername() called before connect() #39040, test(tls): cover pause() and pauseOnConnect around the handshake on accepted and dialed sockets #40375, and what was still real of net: stop surfacing TLS traffic on the socket that tls.connect({ socket }) / new TLSSocket(socket) took over #36534.
SNI, ALPN, server contexts: node:tls: keep every addContext() entry for the next listen() #43080, node:tls: build the tls.Server SecureContext in setSecureContext() #42050, tls: harden SNI name matching (ASCII case folding, one-label wildcards on HTTP/3) #37195 + tls: a later serverName entry replaces an earlier one in the SNI registries #43849 as one change (one SNI matcher for TCP and HTTP/3), tls: select the certificate by server name for connections accepted before close() / graceful stop() #42355, Bun.serve: graceful stop() also drains TLS connections parked in the handshake queue #42285, node:tls: keep ALPN across an SNI SecureContext selection #33253, part of cluster: hand TLS workers their connections on Windows instead of sharing the listening socket #37896, part of Reject interior NUL bytes in hostnames, IP addresses, and SNI servernames #37013. A tls.Server has one SSL_CTX.
Verification and options: node:tls: count a falsy key, cert, ca or crl on tls.Server as absent, like Node #44738, Reject a tls array in Bun.listen and Bun.connect #41490, tls: reject keyFile/certFile/caFile/dhParamsFile paths with embedded NUL bytes #37005 + the cwd pin of tls: resolve relative file paths at parse time and read them from Rust when the SSL_CTX is built #40984, crypto: fix X509Certificate.ca returning true for certs without basicConstraints #31811, tls: match an IPv6 server name with a zone id on its address #43982, tls: don't request client certificates just because a ca was supplied #33483 + tls: don't let NODE_TLS_REJECT_UNAUTHORIZED=0 weaken a server's rejectUnauthorized default #35245, tls: apply tls.DEFAULT_CIPHERS to servers and every TLS context built without ciphers #41810, node:tls: accept Ed25519 server certificates during client verification #32235, tls: trust a pinned self-signed certificate whose keyUsage lacks keyCertSign #44441, types: declare crl on Bun.TLSOptions #38092.
node:tls API and CA store: tls: ignore a late setSession() instead of aborting (SSL_set_session returns 0) #41671, tls: apply sessionTimeout to TLS 1.3 sessions too #38145, node:tls: fix getCipher().version, getEphemeralKeyInfo(), client STARTTLS, and checkServerIdentity exception handling #32824, node: give four ERR_* codes Node's message text and throw ERR_TLS_PROTOCOL_VERSION_CONFLICT #43594, node: tls v26 compat: engine validation, keepalive delay units, reinitialize handle, setMaxSendFragment, cleared timer _idleTimeout (+7 tests) #39997, node:tls: list supported ciphers in getCiphers() and export the SecureContext class #41696, tls: serve every identity from the array form of key/cert #33534, node:tls: make rootCertificates non-configurable #34748, tls: print one warning for a NODE_EXTRA_CA_CERTS file that cannot be loaded #42991, tls: read a pipe or FIFO in SSL_CERT_FILE once for both CA stores #42996, docs: document SSL_CERT_FILE and SSL_CERT_DIR #42970.
node:https, Agent, ws, node-fetch: node:http: http.Server ignores TLS options, https.Server always speaks TLS #41672 (https half), node:https: forward crl, sessionTimeout, ecdhCurve, sigalgs and honorCipherOrder to the TLS listener #41641, node:http: enforce blockList on https servers and on server.blockList assignments #38261, node:https: key the Agent pool name by what object-valued and file TLS options hold #42498, node:https: handle invalid TLS options in proxied requests #44346, node-fetch: forward TLS options from the agent to fetch #35609, ws: forward top-level TLS options (rejectUnauthorized, ca, ...) to the connection #31397, ws: unseal tls.pfx into key/cert before the native WebSocket connects #42325.
WebSocket client: WebSocket: honor tls.serverName and call tls.checkServerIdentity on the client handshake #41648, websocket: close the proxy connection when a tunneled wss:// client tears down #37487 + WebSocket client: close a wss:// socket that the server never closes after the closing handshake #43048 as one change.
SQL, Redis: Bun.SQL(postgres): send plaintext startup when sslmode=prefer and server declines TLS #33666, sql: close a TLS socket at once instead of waiting for the peer's close_notify #41711, sql(postgres): honour PGSSLMODE=verify-ca/verify-full next to a TLS_* connection URL #44498, part of sql, redis: call tls.checkServerIdentity, honor tls.servername, send SNI from RedisClient #42054.
Tests only: test(node:tls): overlap the OOM child with the syscall fault tests and tighten assertions #41426, test: cover terminate() on a TLS socket sending a bare RST #40040, test(net): run the TLS handshake-queue fixtures over a unix socket on macOS #44395, test: run the cluster setSecureContext test with one process #44016, test(tls): run fewer destroySoon connections under debug/ASAN #37860, test: pin the redirect-hop TLS identity and the tunnel SNI from tls.servername #40591, test: cover listener.stop(true) from alpnCallback and serverName #44440, test: run 27890 custom lookup TLS test in-process and assert SNI #41424.

Found on the way and fixed here: an upload that a TLS 1.2 server interrupts with a renegotiation never completes on main (0 of 32 runs over https.request, fetch, node:tls and Bun.connect: the renegotiation ClientHello lands inside an application record that is still unsent, or the socket gets no drain again) and completes here, with two tests from robobun; the fix for #40653 (final flight and first write in one segment) stopped working whenever another TLS socket on the loop was stalled, on main too; the tls.Server prototype pinned the last server constructed and every SSL_CTX it owned; Object.create(process.env).NODE_TLS_REJECT_UNAUTHORIZED = "0" turned verification off process-wide once a SHARE_ENV worker existed; two debug panics when wrapping a shut-down or still-connecting socket; a fetch POST through a proxy sent its headers twice when the origin renegotiated; BlockList ignored IPv6 zone ids; a test now ties root_certs.der to certdata.txt.

Behavior changes

A server's ca without requestCert no longer asks for a client certificate (Bun.serve, Bun.listen, HTTP/3, node:tls). It matches the docs and Node. On main such a server refused clients with no certificate but served any unrelated self-signed one, so it was never authentication. Set requestCert: true to require a certificate. A matrix test pins that requestCert: true still refuses no certificate and an untrusted one on 8 kinds of server, TLS 1.2 and 1.3, with NODE_TLS_REJECT_UNAUTHORIZED unset and 0.
NODE_TLS_REJECT_UNAUTHORIZED=0 no longer relaxes a server.
Bun.connect / Bun.listen hear of a fatal TLS error after the handshake through error(socket, err). With no error handler the socket just closes.
HTTP/3 server names match like TCP: *. covers exactly one label, case is ignored, a trailing dot is ignored, the last registration of a name wins.
requestCert on node:https is === true, as in Node.
An array where a generated options dictionary is expected throws (tls: [], jest.useFakeTimers([])).
key / cert arrays serve every identity. A client that can use both gets ECDSA, where main served whichever pair came last.
ecdhCurve is forwarded by node:https, ws and node-fetch now, so a group BoringSSL lacks (X448) throws there as it already does in tls.createServer.
A wrapped socket's error is re-emitted on the TLS socket as in Node, so raw.destroy(err) with a listener on raw only is uncaught, as in Node.
sql.options.tls is always an object, never true. RedisClient sends SNI.
tls: { secureContext } alone asks for TLS on Bun.listen / Bun.connect (it was plain TCP), and a value that is not a SecureContext throws. The context is served as it is: the requestCert / rejectUnauthorized it was created with hold whatever the options next to it say, and requestCert in the options over a context that does not ask throws at listen().
tls.DEFAULT_CIPHERS reaches every client once assigned (fetch, WebSocket, Bun.connect, RedisClient, Bun.SQL, S3Client, proxy tunnels) and servers again. A list that selects no cipher throws ERR_SSL_NO_CIPHER_MATCH at the assignment. fetch.preconnect() dials nothing after an assignment.
The warning for an unreadable NODE_EXTRA_CA_CERTS is Node's one line, without the warn: prefix.
BUN_CONFIG_WS_CLOSE_TIMEOUT (default 30 s): how long a WebSocket client waits for the server to close the connection after the closing handshake.

Worth a look in review

tls: queue unsent ciphertext per connection so write() counts every sealed record #44529: the kernel-refused remainder of a TLS write moves from the loop's one slot onto the connection (in the existing rare struct), so the write BIO never refuses a sealed record. Nothing is allocated on an unstalled path (200 writes: 0 appends, same send() count as main), memory with 16 stalled writers is lower than on main (276 KB vs 340 KB, which main holds inside BoringSSL's buffers), us_socket_t stays 80 bytes. It needs a bound on how long a deferred close waits, or a peer that stops reading pins the fd past destroy(): US_SSL_CLOSE_AFTER_SPILL_TIMEOUT is a fixed 10 s, not re-armed on progress. Separate commits, but the fix that keeps the client certificate off the wire beside a stalled socket builds on them.
The default name check of node:tls also runs inside the handshake, so a wrong-name server gets no client certificate on TLS 1.2 either. JS still runs it after every successful handshake, so a difference between the two matchers can only refuse. Error objects are byte-identical.
tls: trust a pinned self-signed certificate whose keyUsage lacks keyCertSign #44441 widens trust by design: a self-issued leaf whose keyUsage lacks keyCertSign (dotnet dev-certs) is its own anchor when the store holds a byte-identical copy. No BoringSSL change. Expired pin, same subject with another key, wrong EKU and a pinned intermediate are tested to fail.
node:tls: accept Ed25519 server certificates during client verification #32235 only adds Ed25519 and ECDSA P-521 to the verify list. A captured ClientHello shows main's list with the two inserted; rsa_pkcs1_sha1 stays.
A stream that a TLS socket wraps, when that TLS socket closes. An earlier state of this branch lost data here while CI was green (found by tls: over a Duplex, the peer's close_notify waits for the writes in flight #44709's report): with the peer closing first, 4 of 8 MiB arrived with TLS in TLS, 4 of 32 MiB on the http2 emit("connection") path, and a write() with no 'error' listener ended the process. Three Node-parity changes only hold together: destroying the wrapped stream at the close (node:tls: destroy the wrapped net.Socket when a TLS wrap is destroyed #38028 + node:tls: report a wrapped socket's connect failure on the TLSSocket #38122 + node:tls: use the stream engine for server-side wraps the native upgrade cannot adopt #38076, node:http2: destroy the accepted socket when an injected connection's TLS proxy is destroyed #38154) is safe only if every write has really completed (node:tls: complete write(cb) and end(cb) over a Duplex when the stream completes the ciphertext #43877), which in turn needs Node's handling of the peer's close_notify, which needs half-open sockets that the GC can collect. So:
- node:tls: complete write(cb) and end(cb) over a Duplex when the stream completes the ciphertext #43877 + tls: ignore a 'drain' that a Duplex transport emits from inside its own write() #44394 are reverted and reopened. A write over a stream completes once the stream has taken the ciphertext, as on main.
- Until the verdict on the peer lets the session through, the application cannot have written over it. There the wrapped stream is destroyed as in Node, with the sessions below it. That keeps the release of the connection after a failed handshake, a rejected certificate and an early destroy(). The same for an http2 socket the application never got, and for resetAndDestroy().
- After that it is main's teardown: a net.Socket only gets the engine's end(), closes at its peer's FIN, keeps its own timeout and reports its own errors. Any other stream is destroyed with the TLS socket.
The regular suites cannot see any of this (999 files were green on every broken variant), so it was steered by eleven seeded differential fuzzers run on this build, main, Node v26.3.0 and the earlier state: close, end(), destroy(), destroySoon(), resets, hung and half-open peers, paused writers, timeouts, two and three sessions deep, over TCP and over Duplexes, before, at and after the handshake, and http2 requests. See "How did you verify".

Known limits

fetch with a checkServerIdentity function still sends the client certificate (not the request) to a server the function refuses. On TLS 1.2 any verdict a JS callback gives is too late, as in Node.
addContext() / SNICallback still do not apply to a server-side socket on the stream engine (emit("connection", duplex), TLS in TLS, unflushed writes, named pipes), as on main.
A CA bundled in a pfx extends an explicit ca only, for ws / node-fetch / WebSocket: the native ca can only replace the default store, and that store keeps SSL_CERT_FILE / SSL_CERT_DIR.
P-521 leaves work on TLS 1.3 only. TLS 1.2 needs secp521r1 in every ClientHello (it.todo).
Once tls.DEFAULT_CIPHERS is assigned, fetch(url, { protocol: "http3" }) is HTTP3Unsupported, as with an explicit ciphers.
addCACert() by hand does not extend the chains of a context with several identities.
A throwing ALPNCallback sends no_application_protocol on both engines. Node sends nothing and its client sees ECONNRESET.
TLS in TLS, peer FIN while the outer handshake runs: the inner socket gets one write EPIPE, where Node gives ECONNRESET (main gives it no error at all).
@SECLEVEL in ciphers is dropped by the ws / node-fetch shims, which used to ignore ciphers. node:tls keeps throwing ERR_SSL_INVALID_COMMAND.
Beside a stalled TLS socket only the first record (16 KiB) of the first write leaves with the handshake flight. The rest goes record by record, which is what bounds the memory of stalled writers.
After a fatal error on an established session the socket emits 'error' and then 'close'. Node emits 'error' and leaves the socket open.
A paused reader whose own write the kernel rejects loses what it had not read yet, with an EPIPE, as on Node. main reports no error there and delivers it.
On main too: a Bun.listen socket without allowHalfOpen that has unsent ciphertext when the client's shutdown() arrives loses that ciphertext (32 KiB), and over plain TCP end() with the peer still sending is a close over unread input, so a reset.
Differences from both main and Node that the differential runs below found and that stay, all with a peer that aborts: ECONNRESET instead of a clean 'end' after the socket's own 'finish' when the peer destroyed with unread data; under TLS 1.2, a zero-length write() followed by destroy() in 'secureConnection' leaves the client without 'secureConnect' (a plain destroy() there matches Node); a TLS 1.2 client that destroys in 'secureConnect' gets no 'session'; a ClientRequest whose handshake fails with an alert emits 'error' and 'close' but no 'finish' (writableFinished is true).
Once tls.DEFAULT_CIPHERS is assigned, fetch.preconnect() opens nothing: fetch() then uses a context of its own, and a socket warmed under the default one would never be picked up.
A TLS send() that the kernel refuses outside a write() call (the drain of unsent ciphertext) is reported with the close, as read EPIPE / read ECONNRESET. Node says write EPIPE. main does not report it at all.
Once the application has a session over a net.Socket (TLS in TLS, http2 emit("connection")), a peer that never sends its FIN holds that socket after the TLS socket closed, as on main. Node destroys it. Two tests of node:http2: destroy the accepted socket when an injected connection's TLS proxy is destroyed #38154 are todo for this. Closing it any earlier (at its 'finish', say) makes the kernel drop what it has not sent yet as soon as the peer's close_notify arrives.
Plaintext that was queued on a socket before it was wrapped (STARTTLS with a backlog) is dropped when the TLS socket is destroyed, or its handshake fails, before the session is accepted. Node drops it too, except on destroySoon(). main sends it.
Over a stream that is no net.Socket, end() can still cut what that stream has buffered, and there is no backpressure, both as on main (node:tls: complete write(cb) and end(cb) over a Duplex when the stream completes the ciphertext #43877).
tls.secureContext (the undocumented door node:tls uses) is not read by a Windows named pipe listener, which builds its context from the options. On upgradeTLS({ isServer: true }) the options next to it are the policy, as with Node's SetVerifyMode.
selectServerName() rebuilds the name tree per ClientHello for injected sockets of a server with addContext() entries: 0.4 µs for 1 entry, 3.7 µs for 10, 41 µs for 100, against 631–1111 µs for a handshake.

Not included

Left open, because they need a decision or are not TLS: #43877 + #44394 (see "Worth a look" 5; #43874 stays open with them), #38548, #38591 (both shrink who is trusted), #41589 (verify-full vs NODE_TLS_REJECT_UNAUTHORIZED=0), #37197, #41706, #43216, #33487, #33545, #36707, #32435, #37255, #28691, #40275, #30314 (features), #38120 (needs the BoringSSL fork, as did #33517, which the stale bot has closed since), #38529 (needs a Windows measurement), #34342, #38232, #43089, #44454, #40451, #42710, #44527, #38088, #38093, #41898. #37896, #42054 and #37013 stay open for the halves not taken. http.createServer({ key, cert }) keeps serving TLS on purpose.

One open question: tls: {} (an object that names no TLS option) is plain TCP on Bun.listen / Bun.connect, here and on main. It is the same trap as tls: [], but changing it changes a Bun default, so it is left alone.

How did you verify your code works?

Every new test fails on main for the stated reason and passes here, except guards that pin existing behavior, each shown to fail when its clause is removed. node:* tests also pass on Node v26.3.0; the few that cannot say which Node version has the behavior.
212 test files that touch TLS, sockets, http, http2, fetch, WebSocket, SQL, Valkey and workers: 6154 pass, 2 fail. Both are seen on main too: serve.test.ts "root range port" (the box runs as root), and worker_threads.test.ts "terminate(): nothing of the worker's runs after the request", which is flaky there and passed in the run below.
58 of those files the way the ASAN lane runs them (LeakSanitizer + BUN_JSC_validateExceptionChecks): 58 files, 48 of them with leak checking, 4132 pass, 3 fail. All three also fail on main: serve.test.ts "root range port", node-net.test.ts "should not leak when connect({path}) fails synchronously on a reused handle" (times out under this environment), worker_threads.test.ts "process.exit() with a shell cp in flight" (a ShellCpTask leak).
647 vendored test-tls-*, test-https-*, test-net-*, test-http2-*: the only two failures also fail on main.
The SNI matcher was diffed against both old matchers: 3 seeds × 1.23 M lookups × 3 registration flavours, every difference in one of the intended classes, TCP and HTTP/3 identical on every lookup.
The headline rows were also driven by hand with scripts against this build, main and Node v26.3.0: cleartext https, crl, tls: [] / { secureContext }, the ca / requestCert matrix, the client certificate on a wrong-name server, late setSession(), destroy() in ALPNCallback, [rsa, ec] identities with an intermediate from ca, WebSocket checkServerIdentity, a corrupted record, the Duplex read above, tls.DEFAULT_CIPHERS.
The setSession() guard was checked against the real abort() at 43 handshake states.
bun run rust:check-all: 12 of 12 targets. tsc, oxlint, source lints, prettier, rustfmt, mordant clean.
usockets' _Nonnull is compiled out of debug builds, so 105 of those files were also run on a local release ASAN build with the CI runner's environment (92 with leak checking): 4595 pass, 1 fail, child_process.test.ts "spawn reports EPERM after dropping privileges", which cannot pass as root and fails on main too.
The close of a TLS socket over another stream ("Worth a look" 5): eleven seeded differential fuzzers, 8,424 scenarios compared, each run on a release ASAN build of this branch, on main, on Node v26.3.0 and on the earlier state of the branch. Against main:
- Data that main delivers in full is cut in 5 scenarios, and about 150 that main cuts arrive in full. Of the 5, in 2 main never notices the peer's close and keeps the socket for good, 2 call end() on the middle one of three sessions over an in-memory Duplex, and 1 does the same on Node.
- No dead timeout, no silent reset and no uncaught error that main does not have (4 uncaught errors fewer).
- A socket stays open where main closes it in 109, and closes where main keeps it in 295. 92 of the 109 do the same on Node or on the earlier state (a destroy() that an in-memory Duplex does not show its peer, half-open peers). 14 wait for a peer that paused reading and so does not read the FIN (tls: pause and resume a wrapped Duplex transport with the TLS socket's reads #42332's backpressure, as in Node); the socket's own timeout fires there. 3 are left: one on a 5 ms timer, two with three sessions over an in-memory Duplex.
- The earlier state of the branch cut data in 173 of the 400 scenarios of one of them, where main cuts none and this cuts none.
- 23 new tests pin what they found. Each earlier attempt at this fix fails the ones that describe it, the earlier state of the branch fails 7, and all pass on Node.
After that change: 999 test files on the release ASAN build (20,246 pass; the 11 files that fail need a database, Docker, DNS or a non-root user, or share a temp directory with a parallel run and pass alone), 61 on the debug build.
TLS over a file descriptor (openssl.c, the path of fetch, Bun.serve, tls.connect, Bun.connect) got the same treatment after the rebase: seeded differential fuzzers on CI's release build of this branch, on main and, for node:*, on Node v26.3.0. Every runtime also against itself for the noise floor, injected faults and known bugs of main as positive controls, and a difference counts only if it shows in 5 of 5 fresh processes.
- node:tls over TCP: 11,500 scenarios (one connection with Node as the oracle line by line; 2 to 60 connections beside stalled neighbours; raw peers that break the handshake). HTTPS: about 136,000 runs over Bun.serve + fetch, node:https, node:http2 and wss://, also with the two ends in different runtimes. Bun.connect / Bun.listen / upgradeTLS: 11,500 scenarios and 720 slow connections, with writers driven by what write() returns, beside up to 6 stalled, dripping, closing or resetting neighbours, and plain TCP as a second oracle. No crash, hang, duplication, reordering or silent truncation, and no change in time or in connection reuse.
- They found six things that main does better, none of which any test showed. All are fixed, each with a test that fails on the build before: what the peer sent lost behind a rejected send() (23 scenarios, and an early HTTPS response lost with only EPIPE), the same silently for a paused reader, server.close() never calling back on a half-open server after a ClientHello and a reset (17), closeAllConnections() taking 12 s with a stalled client, end() losing up to 1.3 of 4 MiB that write() had reported while the peer still uploads, and end() a little after a stall never closing beside other stalled TLS sockets. The last two fixes also deliver the 1 to 2 MiB that main loses there, and close the socket that main keeps for good without such neighbours.
- All of them again after every fix, on CI's release build of it. That caught one regression of a fix itself (a reader stopped for backpressure lost 86,385 bytes, 1 of 6,000 scenarios), fixed too. On the last build: scenarios that lose data where main does not 23 → 2, and Node loses it in both, with the same EPIPE; server.close() that never calls back 17 → 0; connections held 4 → 0; requests that end in an error only where main has a response 6 → 0. With a Node server in another process, a request ends in an error only in 8 and 10 of 1,500 scenarios here, 5 and 3 on main, 10 with Node as the client.
- Bun.connect / Bun.listen on the last build against main, in scenarios: hangs 0 against 1,031, sockets and fds never released 0 against 965, corrupted data 0 against 345, abort() 0 against 26 (setSession() after the handshake), writers that never close 0 against 101 of 720 connections. No kind of failure shows here and not on main. About a third of the slow connections close later than on main, in 1 to 16 s instead of at once, waiting for unsent ciphertext or for the peer's close_notify, and 79 more of them deliver all that write() reported. RSS and time with 16 to 256 stalled writers are the same.
- What they found that main does worse: a WebSocket that calls close() with sends pending loses messages in 81 of 999 scenarios (0 here), 37 server sockets left open, 10 server.close() that never call back, 20 write callbacks that never run.
The kqueue fix cannot be run on Linux. The connectionListener count test now says what became of a missing connection, which is how the cause was found ('tlsClientError' "socket hang up", then read ECONNRESET at the client of the same port, after its 'secureConnect'). On macOS x64 it failed every attempt of the three builds before the fix and passed at the first attempt of the build with it.
Windows and macOS were only run by CI. Four new tests asserted what only the Linux kernel does (a FIN read ahead of a reset, unread bytes surviving a reset, loopback buffer sizes, fstat() on a socket) and now say so per platform.

#44618 is in main. Its arm in the EOF block defers the FIN of a socket in the low-priority queue, which covers kqueue and libuv. This branch now extends that arm to the hangup that epoll reports, and keeps the checked registration in us_internal_handle_low_priority_sockets. Conflicts: the imports of socket.test.ts and the end of node-tls-duplex-end-verify.test.ts, where both sides added tests. The burst tests move out of the describe that main made concurrent, because they count what one loop iteration does.

…n native transports (consolidates the open WebSocket PRs) (#45223) ### What does this PR do? This PR replaces the open WebSocket pull requests (listed in the table at the end) with one change. It covers the global `WebSocket` client, `Bun.serve({ websocket })`, the built-in `ws` package, the parts of `node:http` that `ws` depends on, undici's WebSocket exports, and the types, docs and tests for all of them. I treated every open PR as a bug report. For each one I reproduced the bug on main, ran the same script on Node 26.3 (undici) and on npm `ws`, checked the RFCs, and then wrote the fix the way the code should have been structured in the first place. Often that meant deleting a mechanism that caused several bugs at once. Many fixes below had no PR. They came out of those comparisons and are marked "(no PR)". Size: native and builtin source outside `ws` is +5,893 / -5,374. `ws.js` (1,744 lines) becomes `ws.ts` (3,399 lines, about 450 of them types). Tests are +22,739 / -1,786. How I decided close calls: - `require("ws")` behaves like npm `ws` on Node. - The global `WebSocket` behaves like the WHATWG spec and Node's global. Bun's extras stay. - `Bun.serve` follows RFC 6455 / 7692 on the wire and does what its docs and types say. ### Behavior changes to look at first These are the changes I expect users to notice. They're listed so that any of them can be vetoed. **Global `WebSocket`** 1. **Real closing handshake.** Before, `close` fired about 0.2 ms after the `close()` call with our own code and `wasClean: true`, no matter what happened next. Now `close()` sends the Close frame, sets `readyState` to CLOSING and keeps the process alive. Once both Close frames are exchanged, the client closes its side (FIN, close_notify), and `close` fires **when the connection closes**, as in Node (undici and npm `ws`) and browsers. The event has the **server's** code and reason (1005 if its frame was empty) and `wasClean: true`. - If the server echoes the Close frame but never closes the connection, the client drops it at the timeout. The close is still clean and still has the server's code. - If the connection ends before the server's Close frame, or that frame doesn't arrive within `BUN_CONFIG_WS_CLOSE_TIMEOUT`, the result is `1006`, not clean. The timeout is 30 s, in practice 32 to 36 s because uSockets sweeps every 4 s. - Cost: a script that ends in `ws.close()` exits one round trip later. If the server never answers, the process stays alive until the timeout. `terminate()` and `process.exit()` are the ways out. npm `ws` also waits 30 s; undici waits forever. - Data queued before `close()` still goes out first. The timeout starts over whenever more of it can be written, so a slow upload isn't cut off (100 MB at 2 MB/s arrives whole, also through a proxy), and a peer that stops reading is dropped one timeout after its last read. Progress means the kernel reports the socket writable: on loopback with the default 30 s, a reader at 20 KB/s counted as stalled and one at 50 KB/s didn't. main waits forever. - Two tests from #44618 pinned the old model on purpose. I rewrote them. 2. **`close()` without a code sends an empty Close frame**, and both ends report 1005, as in browsers, Node and npm `ws`. A `Bun.serve` `close(ws, code)` handler now sees 1005 when a Bun client calls `close()`. When the server closes first, the client echoes what it received: 1001 stays 1001, empty stays empty. 3. **One failure path.** Whenever the client fails the connection (bad handshake, TLS, proxy, protocol error, message too big, invalid UTF-8, bad close code), it fires `error`, then `close` with **1006**, reason `""`, not clean. Before, `close` had 1002 / 1007 / 1009 / 1011 / 1015 with an English reason, sometimes `wasClean: true`, and often no `error` fired. The text is now in `ErrorEvent.message`, and `ErrorEvent.error.code` is new (`ECONNREFUSED`, `ENOTFOUND`, `DEPTH_ZERO_SELF_SIGNED_CERT`, `ERR_TLS_CERT_ALTNAME_INVALID`, `WS_ERR_INVALID_UTF8`, ...). If the failure happens after open, the client sends a Close frame with 1002 / 1007 / 1009 first. Losing the TCP connection after open isn't a failure: only `close` 1006 fires, with reason `""` (was "Connection ended"). 4. **The 101 response is validated strictly.** The connection fails if the server picks an extension or permessage-deflate parameter that wasn't offered or is invalid (RFC 6455 9.1, RFC 7692 7.1). That includes a server that echoes `client_max_window_bits` without a value. A response head over `--max-http-header-size` + 1 KB now fails no matter how TCP splits it into reads. Before, a head of about 17 KB or more got through if it arrived in one read. 5. **Header values are sent one byte per code unit**, like `fetch` and Node: "café" is `63 61 66 e9` (was UTF-8). `Host` / `Proxy-Connection` in `proxy.headers` replace Bun's own line in the CONNECT request. `fetch` shares that writer, so this changes `fetch` too. 6. `terminate()`, a failed connection and the close timeout now close with a FIN instead of a RST. The kernel still sends a RST if data is unread. The client answers a peer's FIN with a FIN. 7. Messages that arrive together with the 101 are delivered after `open`'s microtasks, as in browsers and undici. npm `ws` has the old order, so `ws` on Bun now differs from it there, in the harmless direction. 8. Smaller changes: - An invalid `binaryType` is ignored (used to throw). - `ws.url` is `ws:` / `wss:` when the input was `http:` / `https:`. - `MessageEvent.origin` is the origin, not the URL with its password. - `bufferedAmount` no longer drops to 0 at close. - `send(Bun.file())` throws (used to send an empty frame). - A ping or pong that nothing listens for is dropped. It used to be queued for a later listener, so a flood of them grew memory to gigabytes. Automatic pongs are unaffected. - Interim 1xx responses count toward the response head's size limit (`--max-http-header-size`). An endless stream of `100 Continue` used to freeze the event loop. **`Bun.serve({ websocket })`** 9. **`websocket.error` is called as `(error, ws)`** and is now typed. It used to be called as `(error)`, so existing handlers keep working and new ones can tell which socket failed. The docs said `(ws, error)`, which never matched the implementation. They now say `(error, ws)`. 10. **`server.stop(true)` closes each WebSocket with 1001 "Server closed"**, including through `using server`. The client and the `close` handler used to see 1006. `stop()` is unchanged. 11. A long `ws.close(code, reason)` reason is cut at 123 bytes on a character boundary. It used to be cut mid-character, so the client saw 1007. Every numeric code is still accepted and sent as before. 12. **`server.upgrade()`**: - reads the handshake from `req.headers` only; - returns `false` once a `Response` has been accepted for the request; - throws for a `Request` that another server received; - ignores `Upgrade`, `Connection`, `Sec-WebSocket-Accept / -Key / -Version / -Extensions`, `Content-Length` and `Transfer-Encoding` in `options.headers`; - treats an empty `Sec-WebSocket-Protocol` in `options.headers` as declining the subprotocol. - Related: an HTTP/1.1 Upgrade or CONNECT request without `Host` gets a 400 (node:http is unchanged). 13. **The configured compressor is actually used.** Every `compress: "dedicated"` / `"4KB"`...`"256KB"` setting ran as `"3KB"`. Each now uses the window its name says, which costs memory. Per connection after traffic: `"dedicated"` 149 → 282 KB, `"128KB"` → 218, `"64KB"` → 186, `"16KB"` → 154. Off, `true` and `"shared"` stay at 2 KB. `"3KB"` is what every setting used to run as. The libdeflate compress fast path is removed (because of the Safari bug described below; numbers are under Performance). `x-webkit-deflate-frame` (Safari 14 and older) is no longer accepted, so those clients run uncompressed. A dedicated compressor accepts and echoes an offer of `server_max_window_bits=8`, as npm `ws` does. The shared compressor (the default) is always 15 bits, so it declines a smaller window, and so does any offer that also has `server_no_context_takeover`. Those connections run uncompressed. Released Bun answered it with 9, which the RFC doesn't allow. (zlib deflates with 9 bits, and that output always inflates with an 8-bit window.) 14. When the server fails a connection, the client now gets a Close frame with 1002 / 1007 / 1009 and the reason. The `close` handler still gets `1006`, but its reason is never empty now. The socket then stays open until the peer's FIN arrives, or for 4 to 16 s. 15. `idleTimeout: 0` arms no timer, so there are no automatic pings either. Those connections used to die at about 256 s. 16. **`maxPayloadLength` no longer applies to Ping, Pong and Close frames.** They have their own 125-byte limit. 17. The error messages of `ServerWebSocket` methods are now consistent with each other. A closed socket still ignores the call, whatever the arguments are. 18. A throw after `server.upgrade()` is no longer swallowed. It goes to `error()` or stderr, the server keeps serving, a surrounding `bun test` fails, and the process exits with code 1 when it ends naturally, same as for any printed `fetch` error. This holds for a sync `fetch`, and for an async one that was really suspended (a timer, I/O) before it called `upgrade()`. If an async `fetch` upgrades before its first real suspension and then rejects, that is still an unhandled rejection and ends the process, as on main. 19. After `server.reload()`, the new `websocket` options also apply to sockets that are already open. The handlers already did. **`ws`** 20. `'error'` gets an `Error` (was an `ErrorEvent`) and is **fatal without a listener**, as in Node. A failed connection attempt, or on a server a hostile frame, ends a process that has no `'error'` listener. 21. `'close'` is `(code, reason: Buffer)` (was a string plus a third argument). It fires when the connection closes, or at `closeTimeout`. Failures are 1006: `'error'` fires immediately and `'close'` when the connection closes, as in npm. (The global `WebSocket` fires both immediately, as undici does.) `close()` without a code gives 1005. `'unexpected-response'` is not followed by `'close'`. 22. A text message is a `Buffer` for every `binaryType`. 23. `ws` servers have no idle timeout, no automatic pings and no backpressure limit. They used to inherit 120 s, a ping at 104 s and 16 MiB from `Bun.serve`. - Automatic Pongs are the one thing still capped at 16 MiB, because the peer controls how many there are. They're skipped while that much is buffered for the socket (RFC 6455 5.5.3; npm queues them all). The cap applies on every transport and also to the clients (`ws` and the global `WebSocket`), which had no cap on main. - The default `maxPayload` is 100 MiB (was 16). - uWS no longer preallocates the whole length a frame header announces before the bytes arrive. It preallocates at most 16 MiB. This also applies to `Bun.serve` with a large `maxPayloadLength`. 24. `WebSocketServer({ perMessageDeflate })` actually negotiates permessage-deflate, and `ws.extensions` is a string. The uWS workaround for Safari 15.0-15.3 no longer applies to `ws` on node:http (npm `ws` has none). `Bun.serve` keeps it. 25. **With an `HttpsProxyAgent`, each hop is verified with its own TLS options**, as on Node. The agent's options (`rejectUnauthorized`, `ca`, ...) apply only to the connection to the proxy, and the WebSocket's options only to the target. Before, both sets were merged and used for both hops, so `new HttpsProxyAgent(url, { rejectUnauthorized: false })`, meant for a self-signed proxy, also turned off certificate checks for the **target**. Code that relied on that has to pass the option to `new WebSocket(...)` too. - All 42 combinations I measured on Node with the real `https-proxy-agent` (14 sets of options, for http→wss, https→ws and https→wss) now give the same result. - The native client gets a new option for this, `proxy: { url, headers, tls }`, also on the global `WebSocket`. With `proxy.tls` (even `{}`), the proxy hop uses only `proxy.tls` and the target only `tls`. Without it, `tls` applies to both hops as before. `serverName` and `checkServerIdentity` are never shared: `tls`'s are for the target and `proxy.tls`'s for the proxy. Proxy agents stay on the native client. - `proxy.tls: true` means `{}`, falsy values mean "not set", and any other non-object throws. `pfx` works in it. - An agent that has neither `connectOpts` nor `proxyRequestOptions` gets no `proxy.tls`, so it behaves as on main. With credentials in an agent's proxy URL, they win over a `Proxy-Authorization` header, as in `https-proxy-agent`. - `'error'` gets the value `checkServerIdentity` returned, as in Node. It used to get a generic TLS error. If the proxy can't be reached, `'error'` names the proxy, not the target. 26. Smaller changes: - A client stays CONNECTING when an `'upgrade'` listener throws, as in npm. It used to emit `'open'`. - A client no longer fails on a `Sec-WebSocket-Version` response header, a repeated `permessage-deflate` entry, or window bits written like `015` or `0xf`, all of which npm `ws` accepts. - `send()` while CONNECTING throws. - `ws.url` is `undefined` on server sockets. - `on*` / `addEventListener` are built on the emitter, as in npm: they use ws's own event classes (not `instanceof Event`), `addEventListener("upgrade")` does nothing, and the `signal` option is ignored. - A server socket is `instanceof WebSocket`. - After `'open'`, only protocol errors are `'error'` events. A reset, a broken TLS record or a failed renegotiation is just `'close'` 1006, as in npm and on main. **Differences from npm `ws` that I kept** (veto any): - An invalid close code throws and leaves the socket OPEN. That matches ws 8.22.0. 8.18.3, the version in `test/node_modules`, leaves it CLOSING forever. - A header whose value is an array is sent as one line joined with ", ". npm sends one line per element. Both join `cookie` with "; ". - `mask: false` / `generateMask` are ignored, `binaryType: "fragments"` gives one fragment, and the `Sender` / `Receiver` classes throw. - After a native upgrade, `req.socket.pause()` doesn't stop reads (`ws.pause()` does), and `req.socket` emits no `'end'`. - `terminate()`: on a server, `'close'` fires before the callbacks of sends made after `terminate()`. On a natively connected client, data that is already buffered is delivered during `terminate()`, not after it returns. `terminate()` in a `'message'` listener drops the rest of the packet being parsed. - A `'message'` listener that throws doesn't stop later messages (npm's receiver stalls). `addEventListener("ping" | "pong")` works. - A Close reason that isn't valid UTF-8 is sent with U+FFFD (npm sends the raw bytes). If that makes it longer than 123 bytes, `close()` throws `RangeError` and the socket stays OPEN. - After the body of a non-101 response, the client closes the connection (Node keeps it for its agent). - `send()` of a file-backed `Blob` throws (npm reads it asynchronously). - Pings aren't answered while more than 16 MiB is buffered for the socket (npm queues a Pong for each, with no limit). - A frame that breaks two rules at once (say RSV2 set and unmasked) is rejected with Close 1002 like in npm, but `'error'` may name the other broken rule. Frames that break one rule get npm's exact error. Released Bun emits no `'error'` and sends no Close frame for any of them. - On a paused, natively connected client, bytes that arrive after `pause()` stay in the kernel's buffer, so `terminate()` and the close timer drop them. Node has already read them and delivers them. - A paused native socket (client or server) doesn't read, so it doesn't see the peer's FIN until `resume()` or `terminate()`. That includes a `createWebSocketStream()` whose consumer has stalled. Node keeps reading up to 64 KiB while paused, so it sees a FIN that follows little or no data. - `req.destroy()`, `req.abort()` or an aborted `signal` inside an `'upgrade'` listener of a natively connected client fails the handshake: `'error'`, then `'close'` 1006. Node emits `'open'`, then `'close'` 1006. I tried Node's order and took it out again: it leaked the connection when a listener threw. - `req.setTimeout()` does nothing on a natively connected client, so an `'unexpected-response'` listener can't change or turn off `handshakeTimeout`, which stays armed until the body ends. Until the response head is complete, `handshakeTimeout` is a fixed deadline that interim responses don't restart. - On a server, send callbacks that are still waiting when the closing handshake finishes run when the connection closes, right before `'close'`, not at the moment of the flush: with no error if the kernel took everything, else with `ERR_STREAM_DESTROYED`. `readyState` is already CLOSED there. On TLS, a drain can report success while uSockets still holds the last record. - If a send callback throws, the ones queued behind it still run, each once. Node drops some of them, depending on how the writes were batched. - `ws.send()` followed by `ws._socket.destroy()` in a `'message'` or `'ping'` listener of a server drops that message. `terminate()` and `close()` deliver it. - Through a proxy, the request passed to `finishRequest` emits no `'socket'` event before `end()`. The native client connects with the final headers, so there is no socket yet. **Not taken**: - #35031 (WHATWG-only close codes): breaks `close(1001)` / `close(1011)`, which work today, with no gain for portable code. - #41712 (env proxy by default): a product decision, stays open. - #36749 (serialize async `message` handlers). - #39255 (keep the ping deadline across sends): TCP already notices a dead peer, and it could drop a slow one that is alive. - #44122, #20533, #37559: refactors. - #35730, #36561: speed-ups of tests that CI skips. - #31205: can't be reproduced. Also not here: - `closeOnBackpressureLimit` over TLS still takes about 12 s to close. It's an old bug, and the fix changes EOF routing in the TLS engine. - `ws.remoteAddress` can still be `undefined` when it's first read inside `close()`. Filling it in eagerly costs a `getpeername` per connection. The docs say to read it while the socket is open; the value is kept after that. - Throws inside `websocket.*` handlers are routed the way they are today. - The `ws` client option `secureContext` is honored on direct connections but still ignored when connecting through a proxy (same as before this PR). ### Changes #### Global `WebSocket` (client) The connected client now tracks two flags (our Close frame was sent, the peer's Close frame was received) and has one exit, `finish()`. The C++ side has one `finish()`, one constructor path and one `sendFrame()`. That replaces six dispatch sites, three copies of the failure block, a 130-line switch and 14 `send` / `ping` / `pong` overloads. Crashes, hangs, lost data: - `send(); send(); close()` lost data. On `ws://` the socket was shut down in both directions right after the Close frame, so anything the server sent next triggered a RST that also destroyed unsent bytes. A plain echo server got 10 of 32 small messages (2 of 32 at 64 KiB) while the client reported `1000`, clean, and 50 ordinary closes caused about 50 RSTs. Now nothing is shut down after the Close frame, and the FIN is sent once both Close frames are exchanged: 32 of 32 in each case, including when the script just ends. (#45196) - `close()` with unsent data queued and a peer that stopped reading never finished, and `terminate()` was a no-op in CLOSING, so the process hung forever. The timeout is now armed when the Close frame is queued. `terminate()` works in every state except CLOSED and reports a close code that was already received. (#36112; the timeout: no PR) - A server's Close frame that arrived under send backpressure left `readyState` OPEN, and later `send()`s were queued behind our own Close echo. (#36112) - A send queue whose tail landed on the end of its ring buffer never flushed the wrapped part (`bufferedAmount` stuck at 7). (#44821) Growing such a queue blocked `send()` for 2.9 / 11.4 / 43.6 s at 16 / 32 / 64 MB. `LinearFifo::realign` is now one `rotate_left`. (no PR in this set; #44929 touches the same function) - `wss://` through a proxy: Close and Pong frames overtook queued messages (`BIN x185, CLOSE, BIN x71`), so 71 of 256 messages were lost behind a "clean" close. (#44822) - A masked Ping, Close or continuation frame from a server was parsed with the mask key as payload, and the connection continued out of sync. Any masked frame now fails the connection. (no PR) - `permessage-deflate; client_max_window_bits=8` was accepted, and then the first compressed message failed with `1011 "Compression not implemented yet"`. (#38632) - `send()` / `ping()` / `pong()` of `Bun.file()` or an S3 file silently sent an empty frame. They now throw `ServerWebSocket`'s error, in every state. (#39082) - A detached buffer hit `ASSERTION FAILED: m_ptr` on debug builds. It's now an empty payload, as in WebIDL, `ServerWebSocket`, `Blob` and `Response`. (#35029, without its TypeError) - `new WebSocket(url, ["ÿ".repeat(357913942)])` aborted the process. (#42216, reduced to the one call site that expands its input) - Deleted `EncodedSlice::utf16_global`, a safe fn that marked a borrowed slice as "C++ frees this". Text frames now reach C++ as an owned string. Fixes #31968. (#31982) - `pause(); close()` kept the fd open (on TLS the server's too) until the timeout. Closing now resumes reading. `ws` is the exception: there the socket stays paused, as in npm. (#42974) Events and state: - Every failed connection fires `error`, then `close` 1006. Subprotocol mismatches used to give `close 1002 ... wasClean: true` and no `error`. (#45122) Failures after open do the same and send a Close frame first. Before, 22 kinds of bad frame reset the TCP connection and reported 1002 / 1007 / 1009 / 1011 without `error`. RSV1 without the extension was `1011`, "clean". An illegal close code from the server was `1002`, "clean". Corrupt deflate data was 1002 and is now 1007. (no PR) - Errors have `error.code`, and the message includes the detail: `Expected 101 status code: 503`, `TLS handshake failed: self signed certificate`, `Proxy connection failed: 403 Forbidden`. (no PR) - A connect failure detected synchronously (a missing unix socket) left `readyState` at 3 right after the constructor and put the whole sentence, URL included, in `close.reason`. It now looks like an asynchronous failure and reports `ENOENT`. (no PR) - The automatic Pong is sent before the `ping` event fires and never after our Close frame. Before, `close()` in a `ping` listener on `wss://` sent an empty Pong after the Close. (no PR) - Events run in the `AsyncLocalStorage` context of the `new WebSocket()` call, as in Node. Sockets created inside a `Bun.ModuleGraph` get their store too. The snapshot leaves out the graph's own frames, so an open socket doesn't keep its graph alive. (#33066) - Frames that arrive with the 101 wait for `resume()` if the socket was paused in `open` or earlier (#43018), and are delivered after `open`'s microtasks (#43696). This takes one field, with no native microtask and no special cases for nested event loops. - `isPaused` is false, and `pause()` / `resume()` return false, unless the socket is CONNECTING or OPEN. (#42978) - After the connection closes, `bufferedAmount` keeps the bytes that were never sent, and then grows only by the payload bytes of later `send()` calls. It used to count framing and pings and skip Blobs. This is what #31760 (already closed) asked for. (#31761, as one snapshot in the single exit, with no FFI override) - A length of 0 encoded in 16 or 64 bits is accepted, like every other non-minimal length (undici and npm `ws` accept them too). A length of 2^53 or more has its own error. (no PR) Constructor and arguments: - Options are read through the prototype chain, stopping at `Object.prototype`. Before, inherited keys and getters were ignored, while `Object.prototype.perMessageDeflate = false` turned compression off everywhere. (#41674) - The documented `protocols: "chat"` threw "Value is not a sequence", and `protocol: "chat"` was dead code. (#41705) A second argument such as `null` or `5` is converted per WebIDL (was `TypeError: Type error`). `['a', 'A']` is a duplicate. (no PR) - One invalid `proxy.headers` entry dropped all of them, including `Proxy-Authorization`. It now throws. (#37638) - `ws://:token@host` sent no credentials, and `user:p%E9ss` sent the wrong password. (#44964) An explicit `Proxy-Authorization` header beats the proxy URL's credentials, matching `fetch` and the target (non-proxy) path. #44964 pinned the opposite. (no PR) - The URL's credentials are kept out of `ErrorEvent.message` and the `SyntaxError`s. (#41698, using `URL::removeCredentials()`; its `fetch` half landed in #42692) - `ping(undefined)` sent "undefined". (#39071) `ping(null)` sends no payload either, (no PR) Opening handshake: - A proxy's 407 was reported as "Proxy connection failed" whenever it arrived in one read, and `HTTP/1.1 200` without a reason phrase was rejected. (#43445) Any 2xx opens the tunnel, as in `fetch`. (#43511) - A 101 with more than 128 header fields failed with "Invalid response". `server.upgrade(req, { headers })` with 125 headers triggers it. (#43243, bounded by the byte limit instead of a new constant) The byte limit gave different results for different TCP segmentation. (#41573, WebSocket half) - `100 Continue` / `103 Early Hints` before the 101, or before the proxy's 200, are skipped. (no PR) - Bytes read while a handshake listener spins the event loop were parsed as a new HTTP head. (#43763, the buffer simplification only) - Header values are sent as latin-1. (#41482) `close()` / `terminate()` while CONNECTING close TCP with a FIN. (no PR) - Found by fuzzing (no PR): the two floods in item 8, and a missing exception check where a binary message is queued because nothing listens yet. - A response of fewer than 9 bytes that can't be HTTP (`foo\r\n`) left the client waiting for the 120 s handshake timeout. It now fails immediately with "Invalid response". A RST instead of a response reports "Connection ended: read ECONNRESET". (no PR) #### `Bun.serve` WebSocket server Crashes and memory safety: - **`server.upgrade(req)` returned `true` after a streamed `Response` had started.** It wrote the handshake headers into the chunked body and then segfaulted the release build (heap-use-after-free at the next `ws.send()` under ASAN). A request can no longer be upgraded once a `Response` has been accepted for it. (no PR) - `ws.subscribe(new String(...))` with a `toPrimitive` that closes the socket caused a heap-use-after-free at the next `publish()`, and `send` / `ping` reported bytes sent on a dead socket. All arguments are now converted first, followed by one state check. Nine methods became four bodies, and `server.publish()` shares their payload helpers. (#39385) - Upgrading a socket that had already been ended (a `ws` `'headers'` listener that calls `req.socket.end()`) was a SEGV on debug and a hang on release. `HttpResponse::upgrade()` now rejects it up front, and `us_socket_adopt` returns NULL instead of the same pointer. The check runs again after the 101 is written, because a head longer than the cork buffer is a real TLS write, which can shut down the socket. `upgrade()` then returns `false`. (#37447, only this part; #44618 fixed its two other paths) - `ws.send(sharedMemory, true)` while another thread writes to that memory overran libdeflate's output buffer. That code path is deleted, and #42318's two race tests pass under ASAN. (#42318 stays open for `Bun.gzipSync` and friends) - `server.reload()` leaked a uWS context per route (12 KiB per reload with 12 routes). There's now one context per owner. A reload refreshes settings and never replaces a live context's closures. (#41680) Lost data, hangs: - A new TEXT / BINARY frame inside a fragmented message was appended to it, and both were delivered as one message. Fixes #33010. (#33011) - `ws.close()` while over `backpressureLimit` lost accepted frames and the Close frame (the peer got 62 of 79, then a bare FIN). `ws.close()` inside `ws.cork()`, `drain`, or `open` after an async upgrade sent its FIN 16 s late. `end()` is now the only writer of a Close frame and owns the uncork and the FIN. (#39843, plus TLS variants of its tests) - `terminate()`, a throwing `open`, `stop(true)` and process exit dropped data that `send()` / `publish()` had accepted in the same tick. (#43711, a third of it; no `flush` flag) A throwing `open` now always lets the 101 be sent first. - The reply to a valid frame was lost when a later frame in the same read failed the connection (Autobahn 3.2, 4.1.4, 5.15). (falls out of #35874) - `idleTimeout: 65536`, `maxPayloadLength: 2 ** 32 + 16` and `backpressureLimit: 2 ** 32 + 1` wrapped to 0, 16 and 1. `idleTimeout` above 960 now always throws, and the other two are clamped. Fixes #13918. (#36998; docs from #40097) - `idleTimeout: 0` meant about 256 s (`0 - 4` in an unsigned short). `static_assert`s now guard the arithmetic. Part of #26554. (#34222) Protocol and API: - When the server fails a connection, it sends a Close frame with 1002 / 1007 / 1009 and the reason. That includes an invalid Close payload, which used to be echoed as an empty Close. Fixes #22723. (#35874, but the handler keeps 1006, which is what npm `ws` and browsers report) - `stop(true)` sends 1001. Part of #25722. (#34961, the `stop(true)` half, in `TemplatedApp::close()`) - permessage-deflate: - The negotiator is new and does a plain split and compare. The old tokenizer compared the *sum of the characters*, so `deflate-permessage` matched. `server_no_context_takeover` or `server_max_window_bits` is honored and echoed, invalid offers are declined, and fallback offers are tried. (#41629) - `compress: false` actually turns compression off, and `decompress: "16KB"` no longer sets the *compressor*. `{ compress: on, decompress: off }` keeps working. (#41637, without its throw) - Inbound BFINAL=1 blocks are accepted. (#33592) - Corrupt data closes with 1007. A message that inflates past the limit closes with 1009. - Each dedicated compressor and each dedicated decompressor uses 4 KB less. - `perMessageDeflate: true` sent messages that end in a final DEFLATE block, which makes Safari close with 1002 (WebKit bug 326651). All outbound messages now end in a sync flush. Fixes #25673. I checked this on the wire; I couldn't run Safari. (no PR) - A long `ws.close()` reason is truncated to 123 bytes on a character boundary. It used to be cut mid-character, so the client saw 1007. (#41665) - `upgrade({ headers })` duplicated `Sec-WebSocket-Accept`, `Upgrade` and `Connection`, and removed a field from the caller's `Headers`. (#41875) `headers: {}` threw, and a subprotocol couldn't be declined. Fixes #18243. (no PR) The result depended on an unrelated `req.headers` read or `await`. (#41962) Another server's `Request` cross-wired handlers and topics. (#41811, `upgrade()` only) - The 101 for an upgrade made after an `await` was sent in 25 writes (33 TLS records). It's now one write. (no PR) - An Upgrade / CONNECT request without `Host` gets a 400. It used to reach `fetch` with a relative URL. (#41670) - `upgrade(); throw`, and a rejection from a handler that upgraded after an `await`, were silently dropped. (#45000, but reported through `error()` / the `fetch` reporter instead of ending the process) `async: upgrade(); throw` is still an `unhandledRejection`. - `websocket.error(error, ws)`, typed. Fixes #11634. (no PR in this set; #41728 touches the types) - New: `ws.pause()`, `ws.resume()`, `ws.isPaused`. The idle timer is suspended while paused. Fixes #32483. (instead of #36749) - `drain` only fires after a `send()` that returned `-1`. A TLS socket used to get one right after the upgrade with nothing buffered, and each `pause()` / `resume()` would have caused one. (no PR) - `ws.cork(cb)` runs `cb` on a closed socket. `server.publish(t, d, undefined)` compresses like `publish(t, d)`. (#39253) `websocket: {}`, the first example in the docs, no longer throws "expects a message handler". (no PR) #### `ws` `src/js/thirdparty/ws.js` (two classes that forwarded lazily to native objects) is replaced by `ws.ts`: one `class WebSocket extends EventEmitter` ported from ws 8.22.0 (`websocket.js`, `websocket-server.js`, `event-target.js`, `stream.js`, `extension.js`, `subprotocol.js`, `validation.js`, and the negotiation half of `permessage-deflate.js`). Framing, masking, UTF-8 validation and deflate stay native, so there is no JS `Sender` / `Receiver`. All nine JS-only PRs together moved the old shim from 18 to 24 of my 212 client cases. The state machine had to live in one place. There are three transports: 1. **Client**: the native client connects. In this mode it calls one shared handler table (`this` = the `ws` object) instead of dispatching DOM events, so there are no listener objects per socket and no `MessageEvent` per frame. 2. **Server**: upstream's code builds the 101 in JS, native code writes those bytes, and uWS adopts the node:http connection into a context that has this `WebSocketServer`'s options. `_socket` is the real node:http socket, and its `'close'` is what emits the `ws` `'close'`. There are no queues and no ticks in JS. 3. **Any JS stream** (the stream transport), both roles: the native client engine reads from and writes to a JS stream. It's the slower path (numbers under Performance), and only these cases use it: - Server: any `Duplex`, `server.emit("connection", socket)`, http2 `allowHTTP1`, fastify's `injectWS`, a manual `setSocket()`, and a node:http connection on which frames were read before `handleUpgrade()` ran. - Client: a custom `agent` (SOCKS agents), `createConnection`, `lookup`, `finishRequest`. These go through the real `http.request()`, which is upstream's own path. `family`, `localAddress` and `localPort` take that path too. Crashes, lost or corrupted data: - **One request from any client ended the process** with an uncaught `TypeError` when the connection wasn't native: `http2.createSecureServer({ allowHTTP1: true })` (`vite --https`), `server.emit("connection", socket)` (socket.io's sticky sessions), or any `Duplex`. They now get a 101 over the stream transport. (#44460: took its native binding and `can_upgrade()`, replaced its 500; #28152's Proxy case is a test) - `await events.once(ws, "open")` on a port that refuses connections killed the process, and `once("message")` + `on("message")` delivered each message twice. (#37972; there are no per-socket closures at all now) - Server: a message after `ws.onmessage = null` was an uncaught `TypeError`, `addEventListener("message")` got a Buffer for text, and `onclose` got a number. Fixes #36060. (#44111) - Server: 64 x 1 MiB arrived as 83 frames, 62 of them out of order, and `close()` behind a backlog delivered 4 of 24. The second send queue in JS is deleted. Fixes #44971, #21376. (#44520, #39802) - `send(Buffer.from([0xff, 0x68]), { binary: false })` arrived as `ef bf bd 68`. `binary` didn't decide the frame type for ArrayBuffer and Blob. `{ fin: false }` sent three whole messages. (#44535: its native entries, plus `fin` and `compress`) - `send()` after `close()` acknowledged a dropped message with `cb(null)`. (#39840) Callbacks now mean "written": they wait if the peer isn't reading, and they fail when the socket dies. (no PR) - `finishRequest` with a late `req.end()` sent two handshakes, and `'open'` never fired. A request that was never ended connected anyway. (#44123, with no deferred native socket) - `maxPayload` was ignored in both directions: a limit of 100 let 101 bytes through, the default rejected 20 MiB, and socket.io's `maxHttpBufferSize` did nothing. It's now a native limit per `WebSocketServer`, checked at the frame header. Fixes #8261. (#36650) Client `maxPayload` works too. (no PR) - A custom `agent` was silently dropped, so a SOCKS proxy the user asked for was bypassed by a direct connection. The agent is now used. The tests run three kinds of SOCKS agent against a SOCKS5 server and check that a dead proxy isn't bypassed. Fixes #23208. (no PR) - Frames that arrive before a *deferred* `handleUpgrade()` (after an `await`, or a `verifyClient` that answers late) were lost: `["later"]` where Node gives `["early", "later"]`. Such a connection now uses the stream transport, which starts with `head` and whatever the socket has buffered. (#43176, without its replay on `nextTick`) - Server `close(999)`, `close(1004)` and `close(-1)` were sent on the wire. (#42011) Features and parity: - The closing handshake, in both roles (#39802; client: no PR): - After `close()` the socket is CLOSING, and messages that arrive before the peer's Close frame are still delivered. - `'close'` reports the peer's code (`4444 "theirs"`, was our own `4000 "mine"`), or 1006 if the peer only sends a FIN. - A listener added after `close()` or `terminate()` fires. - `terminate()` after `close()` is 1006. - `close()` leaves a paused socket paused. - The `closeTimeout` option works. - uWS got a mode for this: write the Close frame, keep reading, and report when the peer's Close, the FIN or `socket.destroy()` arrives. `Bun.serve` doesn't use it. - `createWebSocketStream()` is upstream's `stream.js`, with backpressure. Fixes #4568. (#35459) - `options.WebSocket` is honored, server sockets are `instanceof WebSocket`, and patches to `WebSocket.prototype` apply to them. Fixes #13317. (no PR) - `ws._socket` is the node:http socket on servers. On clients it's a small object with `remoteAddress` / `remotePort` / `remoteFamily`, `ref()`, `unref()` (engine.io-client's `autoUnref`) and `destroy()`. (no PR) - Server `pause()` / `resume()` / `isPaused`. Fixes #44453. (#44554; the tests fail against a `pause()` that only sets a flag) - Options that were accepted but ignored now work. Client: `handshakeTimeout`, `origin`, `auth`, `followRedirects` / `maxRedirects` / `'redirect'`, `protocolVersion`, `autoPong`, `skipUTF8Validation`. Server: `autoPong`, `skipUTF8Validation`, `perMessageDeflate`. `handshakeTimeout` and `closeTimeout` are no longer capped by the native 120 s / 30 s timers, because no native timer runs for a `ws` client. `protocolVersion: 8` is actually sent, with `Sec-WebSocket-Origin`. (no PR) - Headers that `'headers'` listeners push are included in the 101 (engine.io's cookies and `headers` event). `handleProtocols: () => false` no longer selects a protocol (graphql-ws). (no PR) - Errors match npm's: `Unexpected server response: 403` for every kind of listener (#36375) and with or without a listener (#45125, minus its two regressions); `connect ECONNREFUSED ...` with `code`; `WS_ERR_*` for protocol errors on both sides, with Close 1002 / 1007 / 1009 on the wire. (no PR) - `req.destroy()` / `req.abort()` work in `'unexpected-response'` and `finishRequest`. (#37973) `ping(null | false)` sends an empty frame. (#39093) Text is a Buffer for every `binaryType`, built natively. (#44255, #44553, #44112) `terminate.call(undefined)` throws. (#34873) - `send(null)`, `send([1, 2])` and `send({})` do what npm does (empty binary, bytes, `ERR_INVALID_ARG_TYPE`). `ping` / `pong` callbacks run later, with `null`. Accessors are enumerable, and the ready-state constants are read-only. `["Foo", "foo"]` are two subprotocols (the global `WebSocket` treats them as duplicates). (no PR) - Bun's extras carry over: `proxy`, `tls`, `HttpsProxyAgent`-style agents (connected natively), `ws+unix:`, `wss+unix:`. - `perMessageDeflate: { serverNoContextTakeover, clientMaxWindowBits, ... }` goes into the client's offer (it was always `permessage-deflate; client_max_window_bits`), and the server's response is validated against what was offered. (no PR) - A RST instead of a response is `read ECONNRESET` with `syscall: "read"`. A FIN is `socket hang up`. (no PR) - The body of a non-101 response in `'unexpected-response'`: `res` now gets the whole body, decoded (Content-Length, chunked with `fetch`'s decoder, or until EOF), even when it arrives after the head. The event itself isn't delayed. Before, a chunked body arrived raw and a body that came after the head was lost, so a gateway's JSON error didn't parse. The body has backpressure: a `res` that isn't read pauses the native read. A complete body sets `res.complete`. A truncated one ends as in Node: `'aborted'`, `'error'` `ECONNRESET`, no `'end'`. (no PR) - A 101 with no value in `Upgrade`, or without the `upgrade` option in `Connection`, is a final response with no body, as it is for node:http's parser: `'unexpected-response'`, then `'end'` on the response immediately. Without a listener it's `'error'` "Unexpected server response: 101". The global `WebSocket` fails such a 101 as before. (no PR) - Found by fuzzing (no PR): - A `handleUpgrade()` that runs a few ms late (an `await`, an async `verifyClient`) lost bytes, or the peer's FIN, that node:http had read but not yet handed to JS. Lost bytes failed a valid client in about 1% of such connections. A lost FIN left the socket open for good, which a remote peer could provoke (main too). Both now take the stream transport. - `req.socket.remoteAddress`, `servername`, `authorized` and `authorizationError` can still be read in `'close'`, whether the upgrade came from an `'upgrade'` or a `'request'` listener. - A send callback that throws no longer skips `'close'`, a stream's `'finish'`, or the callbacks behind it. On the stream transport each runs exactly once, although node:net on Bun drops some write callbacks and repeats others. - `handshakeTimeout` also covers the body of an `'unexpected-response'`. A refused upgrade behind a pipelined request answers on the right response. `createWebSocketStream()` finishes when the closing handshake is done. - `tls` / `proxy.tls`: inherited, non-enumerable and getter options are honored, also next to a `pfx`, and `Object.prototype` is ignored. #### node:http - `socket.bytesWritten` of an `'upgrade'` / `'connect'` socket was 0. It now counts raw writes (queued ones too) and the 101 that `ws` sent, and it keeps its value after close. `bytesRead` counts the tunnel's bytes. engine.io closes every upgraded socket on its `http.Server` whose `bytesWritten` is 0 after 1 s, which is the cause of "vite / SvelteKit dev + socket.io reloads every second". Fixes #23747. (#45030: its sum and its test lines, plus corked, backpressured and closed sockets) Not counted: WebSocket frames after a native upgrade, and HTTP heads in `bytesRead`. - A node:http server no longer registers a `Bun.serve`-style `websocket` route. The `NodeHTTPResponse` arm of `server.upgrade()`, `NodeHTTPResponse::upgrade()` and `UpgradeCTX` are deleted (375 lines). - Pinned by tests: `socket.destroy()` and `socket.setTimeout(0)` after an upgrade; `http.Server#close()` leaves `ws` connections open. #### undici - Added `require("undici").ping(ws, body?)`, and `undici:websocket:ping` / `:pong` on `node:diagnostics_channel`, with a `Buffer` payload for every `binaryType`. Without them, Slack Socket Mode / Bolt reconnected forever. Fixes #37110. (#37111, with two shared listeners instead of two closures per socket, undici's order of argument checks, and `"blob"` handled) - `require("undici").WebSocket` is now a subclass of the global one instead of the same object. Only its sockets publish to those channels. The `open` / `close` / `socket_error` channels stay silent. #### Types and docs - `error` / `onerror` are `ErrorEvent`. Fixes #36329. (#42673, #39069) Added `ping` / `pong` events, `binaryType: "blob"` and `Blob` payloads. (#39069) `headers` accepts `Headers` and pairs, and with lib.dom loaded, `Bun.WebSocket`'s `message` event has `.data` again. (no PR) The fixtures assert on `Bun.WebSocket`, so the list of expected lib.dom diagnostics didn't change. - `serve.d.ts`: `error?(error, ws)`, `pause` / `resume` / `isPaused`, `message?` is optional, `cork<R>` (its `T` shadowed the data type), option ranges and what 0 means, `close()` codes, compress defaults, and four examples that called the wrong method. - `websockets.mdx`: every example runs and type-checks as pasted (the first one threw). New "Closing connections" and "Errors" sections. One Origin check for cookie-authenticated upgrades, which allows a missing `Origin` so that non-browser clients work (#36155). Also compress defaults (#39253), backpressure (#41679, WebSocket half), `pause()` (#42976, the paragraph but not its JSDoc) and casing (#42443). The hand-copied Reference block had drifted on nine members and is replaced by links, which makes #40879 moot. - `ws.ts` is fully typed (`tsc` on `src/js`: 0 errors, also with `noImplicitAny`). Adding the types left the generated module byte-identical. #### Tests - #39370 took `websocket-server.test.ts` on a debug build from 40 s with 4 timeouts to 13 s and green (the file has grown since). - The writev fault test never reached `us_socket_write2`. (#38174) - `websocket-pause.test.ts` streams 32 MiB instead of 256 MiB and fails immediately when a send is dropped. (#41109, the constant and about 15 lines) - `ws-syscall-fault.test.ts` went from 7.6 s to 3.2 s on debug. (#37115, without the asserts that froze four differences from npm) - `setSocketOptions()` of `bun:internal-for-testing` (`SO_SNDBUF` / `SO_RCVBUF`) now takes any socket Bun owns: a `ws` or global `WebSocket`, a `ServerWebSocket`, TLS sockets, node:net and node:http sockets. It also works on Windows, where it did nothing. With a 64 KiB send buffer a sender hits backpressure after about 200 KB instead of 4.2 MB, so the backpressure tests send 1 MiB instead of 12 to 64 MiB. - No test sits through a real close timeout (uSockets sweeps every 4 s, so "1 s" is 4 to 8 s). Those were removed, and the numbers are under "Fuzzing before merge". - Autobahn fan-out (#35421): not run here, it needs docker. - `hostname: "127.0.0.1"` where a test connects to 127.0.0.1. (#41331, plus `websocket-proxy.test.ts`) I haven't swept the other files that have the same pattern. - Two stale `todo`s are now real tests, and so are `ws`'s five early-frame `todo`s (#43176). The empty `perMessageDeflate` todo and an empty `skip` are removed. - New in `test/js/first_party/ws`: the `ws-*-compat-*.test.ts` files, `ws-stream-transport.test.ts`, a rewritten `ws-upgrade-events.test.ts` (18 files) and one raw-peer helper. Every block runs twice: on the built-in, and on `node_modules/ws` loaded by path. No sleeps. ### Performance **`bench/websocket-server`** (the chat room in this repo, 32 clients in 4 client processes as its README suggests, server on 4 reserved cores, 6 interleaved rounds, this PR at `6564a70`): Throughput against main: `Bun.serve` pub/sub -1.1% (main against a copy of itself: +1.4%), `ws` -4.6% (copy: -4.1%). That's inside the noise, so I also counted instructions per delivered message. `Bun.serve`: 758 on main, 775 here. `ws`: 12,477 on main, 12,628 here (95% of the time is in the kernel's TCP stack). **Receiving compressed messages in a client** (global `WebSocket`, server without context takeover, which is `Bun.serve`'s default; user-space instructions per message, this PR at `6605b96`): | JSON message | main | this PR | |---|---|---| | 512 B | 35,958 | 16,375 | | 2 KB | 57,948 | 26,022 | | 16 KB | 224,533 | 101,941 | | 64 KB | 718,398 | 333,248 | The client tried libdeflate first, which can't inflate an unfinished stream, so it decoded every message, failed at the end, and zlib decoded it again. It now appends a final empty block, as uWS does on the server, and only uses libdeflate without context takeover. **My own scripts:** Both binaries are CI's own release builds: this PR at `d51fcce`, and `9510e74`, the main commit it's based on. 8 physical cores were reserved: 4 for the side being measured and 4 for the other end, which is always main's binary. Runs are interleaved, and each number is the median of 7 rounds. "main again" is a byte-identical copy of main's binary, so the difference between the first two columns is the noise. `ws` client (echo server: main's `Bun.serve`): | shape | main | main again | this PR | |---|---|---|---| | ping-pong 64 B, round trips/s | 43,469 | 43,838 | 46,403 | | pipelined echo 64 B, msg/s | 261,627 | 263,397 | 299,713 | | echo 16 KB, msg/s | 98,230 | 94,591 | 97,603 | | compressed echo 2 KB, msg/s | 106,904 | 106,657 | 107,253 | | idle connection, KB | 9.2 | 9.1 | 10.4 | `ws` server (load generator: main's native `WebSocket`): | shape | main | main again | this PR | |---|---|---|---| | ping-pong 64 B, round trips/s | 43,011 | 43,784 | 45,172 | | pipelined echo 64 B, msg/s | 271,840 | 276,301 | 273,717 | | echo 16 KB, msg/s | 81,858 | 83,697 | 82,962 | | `send()` to 100 clients in a loop, 128 B text, deliveries/s | 345,531 | 352,509 | 381,826 | | idle connection, KB | 7.9 | 7.7 | 7.4 | The loop row is `for (const c of wss.clients) c.send(data, { binary: false })`, not pub/sub. It measures per-`send()` overhead. The old shim decoded the `Buffer` to a string on every such call; the new code passes the bytes and the opcode straight through. Compressed echo on the server can't be compared, because the old shim never negotiated permessage-deflate. The global `WebSocket` client and `Bun.serve` are level with main on the same three shapes (ping-pong, pipelined echo, echo 16 KB): every difference is under 1.6%, and main differs from its own copy by up to 2.4%. `Bun.serve`, `ws.send(x, true)` echo with the libdeflate compress path deleted (older numbers: local release builds, a busy machine): the shared compressor is 10% to 2.5x faster than main from 64 B to 16 KB. The dedicated one is 7% slower at 64 B and 1.3x to 5x faster from 512 B to 16 KB. Bytes on the wire for 64 B to 4 KB slices of `package.json`: the shared compressor is within 4 bytes of main, and the dedicated one is 11 to 26% smaller from 512 B up. Supporting the server role in the client engine costs a natively connected client one predictable branch per received frame and two per sent frame. The global `WebSocket` table above measures that. Every `JSWebSocket` cell grew by 16 bytes (owner and handler table). Each upgrade client is 4 KB smaller (a header array was removed). Binary size: +64 to +128 KB per target (CI's table). ### How did you verify your code works? **Oracles.** Node 26.3.0 (its global `WebSocket` is undici 8.3); npm `ws` 8.18.3 (the repo's test dependency), on Node and, loaded by path, on Bun; the source and tests of `ws` 8.22.0; RFC 6455, RFC 7692 and the WHATWG standard. Where Node and a spec disagree, I say so above. **Against Node + npm `ws`** (release build): | what | main | this PR | |---|---|---| | `ws`'s own test suite, 271 tests, in a sandbox without network | 94 | 234 | | 212 client cases: one process each, raw `node:net` peer, output compared with Node's byte for byte | 18 | 179 | | 159 server cases, same method | 67 | 150 | | new permanent suite, built-in rows that fail (measured at 1,233 rows; it has grown since) | 800 of the 1,082 that finish | 0 | - The remaining failures in `ws`'s own suite reach into the JS `Sender` / `Receiver` / `net.Socket` of a natively connected client (`ws._receiver`, `ws._socket.on`, `generateMask`, file-backed Blobs), which don't exist here. - The remaining client cases differ in the wording of engine errors (V8 / JSC), ws 8.22 versus the 8.18 that produced the recorded output, the order of request headers, and the kept differences listed above. **Each new or changed test was first run on main's release build**, and I read the failure. It has to fail for the stated reason, not by timing out. Some new tests pass on main: they pin existing behavior to guard the rewrites. **Debug + ASAN build**, with `BUN_JSC_validateExceptionChecks=1` as on CI's ASAN lane: every file under `test/js/web/websocket`, `test/js/bun/websocket` and `test/js/first_party/{ws,undici}`, plus `node-http`, `node-https`, `node-http-connect`, `node-http-with-ws`, `node-tls-connect`, `bun-server`, `request-smuggling`, fastify-websocket and `bake/deinitialization`. 80 files and 6,001 tests, all pass. - Wire logs from a raw peer and the client on one clock: `send` x 32 + `close` delivers 32 of 32 (main: 10, and 2 at 64 KiB); 256 of 256 through the tunnel with the Close last; Pong before Close on `wss://`. **CI**: every platform built, and the new `ws` suite passed on macOS and Windows. **Fuzzing before merge.** Up to seven agents, one area each, ran seeded generators in a jail on CI's release builds of this PR, main, released Bun and Node, and on debug + ASAN. After each round I fixed what they found, another agent turned each repro into a test that fails on the old binary, and the hunt ran again on the new one. | | round 1 | round 2 | round 3 | round 4 | |---|---|---|---|---| | cases | over 1M | 400k | 300k | 200k | | crashes, sanitizer reports | 0 | 0 | 1 use-after-free | 0 | | regressions from main | 6 | 5 | 0 | 0 | | bugs in the fixes of the round before | | 6 | 5 | 2, low | - Proxy trust: over 350,000 combinations of options, certificates and routes against a model. Nothing opened that must be rejected, and no credential or client certificate reached the wrong peer, except a `pfx` next to inherited or hidden options (fixed). The same model flags main in 90 of 800 cases. - The use-after-free came from one of my fixes for round 1: it ran the `ws` drain handler after uWS's close handler, when GC may already have freed the native socket. It needed a script that clears private symbols. That code is gone, and uWS again calls nothing after the close handler. - Close timeout, measured on CI's release build on ws, wss, a unix socket and through http, https and authenticated proxies: `send(100 MB); close()` at 2 MB/s delivered 82.5 MB and closed 1006 before the fix, 100 MB and a clean 1000 after it. A peer that stops reading at once, halfway or 1 KB before the end is dropped one timeout after its last read. One that reads everything but never answers is dropped one timeout after the flush. - Late `handleUpgrade()`: 9 of 1,250 connections lost bytes before the fix, 0 of 1,500 after it, then 0 of about 50,000 generated cases of valid traffic (the generator fails 119 of 8,000 on the build before). **`Bun.serve` against main**, for "keeps accepting what released Bun accepts": the same 8,700 server calls, 1,492 client calls, 26 handshakes and 19 close codes on both. What only this PR refuses: an HTTP/1.1 upgrade without `Host`, a repeated `Sec-WebSocket-Key`, `idleTimeout` of 65,536 or more, and `upgrade()` with another server's request. Five more were found this way and taken out. At scale (50,000 connections, a 20-minute soak with 438,000 connections, fan-out, dead consumers, reconnect storms, `stop()` / `reload()` with 20,000 open) only item 13's memory and item 10's close code differ from main. **Two security scans** of the whole diff found nothing above low severity except two denial-of-service bugs in `ws`. All four findings were reproduced and fixed with tests: - Unbounded automatic Pongs (described above). The cap is on all three transports, because a peer can choose the transport by sending a frame before a deferred upgrade. - A redirect `Location` (`/#`, `ws+unix::/x`) threw out of the native handshake callback and ended the process. - Bun's `tls: { ca, checkServerIdentity, ... }` option was dropped whenever the client connects through `http.request()` (`finishRequest`, `lookup`, `family`, ...), so a certificate pin was lost (1.4.3 enforces it). - `tls`, `proxy` and `agent` could be set through a polluted `Object.prototype` (1.4.3 has one such case too). **A review of the whole branch** found 15 issues, fixed with tests. The worst: a use-after-free of the server when `handleUpgrade()` gets a request from a server that was already freed, a stream wrapping the socket that `handleUpgrade()` bypassed, and the ignored client options `signal` and `secureContext`. **Lints**: `cargo clippy --workspace`, `cargo check --workspace --all-targets`, `rust:check-all` (every target), `bun lint`, the three `tsc` projects, clang-format, rustfmt, prettier, `test/internal/source-lints`. **Types**: `bun-types.test.ts` passes 22 of 22. With main's `.d.ts` and the new fixtures, 10 of 22 fail. **Not run**: - #44633's script on Windows. It's worth trying, since the 101 and the Close now leave in one write. Some backpressure tests are skipped on Windows, as they were in the original PRs. - Autobahn (needs docker), Safari, WebView with a real Chrome. - "No ping and no idle close on a `ws` server" has no automated test, because it needs 135 s. I checked it by hand, with the three options injected into main. ### The pull requests Thanks to the outside contributors whose reports and patches are in here: @C0casio45 (#28152), @hughescr (#34222), @steipete (#44553, #44554, #45030), @davidhevn (#42673), @deepshekhardas (#40879, #42443), @ousamabenyounes (#36749), @alex-mextner (#31205); and to @1cedsoda, whose #44061 / #44165 stay open. "ext" = from an outside contributor. taken = as it was, or nearly. reworked = same bug, different fix. superseded = falls out of a larger change here. | PR | author | verdict | why | |---|---|---|---| | #20533 | Jarred-Sumner | not taken | clang already emits `bswap` / `rol`, so the assembly is identical | | #24914 | Jarred-Sumner | obsolete | fixed by #25475; in BoringSSL the line marks every TLS socket low priority | | #28152 | C0casio45 (ext) | obsolete | next-ws awaits before `handleUpgrade()`; #39642 fixed that. Proxy case kept as a test | | #31205 | alex-mextner (ext) | not taken | its cases compile on main; I widened `headers`, which is probably what the author hit | | #31761 | robobun | reworked | one snapshot in the single exit; counts payload bytes only | | #31982 | robobun | taken | | | #33011 | robobun | taken | plus BINARY inside TEXT | | #33066 | robobun | reworked | one `dispatchEvent` override, not 20 renamed call sites | | #33592 | robobun | taken | | | #34222 | hughescr (ext) | reworked | the one-line fix + `static_assert`s; no test binding, no 20 s tests that pass without the fix | | #34873 | robobun | superseded | by the port | | #34961 | robobun | reworked | `stop(true)` half only; `stop()` stays graceful as documented | | #35029 | robobun | reworked | `span()` kept; detached = empty, no TypeError | | #35031 | robobun | not taken | breaks `close(1001)` / `close(1011)` | | #35421 | robobun | taken | | | #35459 | robobun | superseded | upstream's `stream.js`, with the backpressure the PR dropped | | #35730 | robobun | not taken | 0.8 s on a test that CI skips | | #35874 | robobun | reworked | handler keeps 1006; 1007 vs 1009 for inflate errors | | #36112 | robobun | taken | plus the missing timeout | | #36155 | robobun | reworked | one check and a short warning; a missing `Origin` is allowed | | #36375 | robobun | superseded | upstream's `abortHandshake`, every kind of listener | | #36561 | robobun | not taken | same as #35730 | | #36650 | robobun | reworked | native limit per `WebSocketServer`; `'close'` is 1006, not 1009 | | #36749 | ousamabenyounes (ext) | not taken | frames from one read still overlap; deadlocks request / response over one socket. `ws.pause()` instead | | #36808 | robobun | obsolete | replaced by #37275 | | #36998 | robobun | taken | | | #37111 | robobun | reworked | shared listeners, `"blob"`, undici's check order | | #37115 | robobun | reworked | `describe.concurrent` only | | #37439 | robobun | stays open | WebSocket half landed in #40624; the rest is `fetch` | | #37447 | robobun | reworked | the early rejection only; #44618 fixed two of its three paths | | #37463 | robobun | obsolete | landed in #43557; test kept | | #37559 | robobun | not taken | refactor of code that #40018 rewrote | | #37638 | robobun | taken | | | #37972 | cirospaciari | superseded | one handler table, so no listeners to install twice | | #37973 | cirospaciari | superseded | one request class; npm's rows | | #38174 | robobun | taken | | | #38177 | robobun | obsolete | fixed by #40566 | | #38632 | robobun | taken | | | #39069 | robobun | reworked | `.d.ts` taken; fixture on `Bun.WebSocket` | | #39071 | robobun | taken | plus `null` | | #39082 | robobun | reworked | the server's error class, one FFI call | | #39093 | robobun | superseded | upstream's line | | #39253 | robobun | taken | plus `publish(t, d, undefined)` | | #39255 | robobun | not taken | a `send()` cancels the ping deadline, as released | | #39370 | robobun | taken | | | #39385 | Jarred-Sumner | taken | ported by hand; `sendBinary`, `close`, ping / pong too | | #39608 | robobun | stays open | not WebSocket; its two `ErrorEvent` lines are here | | #39802 | robobun | reworked | no JS queue, no tick; native "wait for the peer's Close" | | #39840 | robobun | superseded | upstream's lines | | #39843 | robobun | taken | plus TLS tests | | #40097 | robobun | superseded | by #36998; docs lines kept | | #40879 | deepshekhardas (ext) | obsolete | the block it fixes is deleted | | #41109 | robobun | reworked | the constant + 15 lines | | #41331 | robobun | taken | | | #41482 | robobun | reworked | Rust only, smaller | | #41573 | robobun | reworked | WebSocket half; `fetch` half dropped | | #41629 | robobun | reworked | new negotiator, fallback offers, no x-webkit | | #41637 | robobun | reworked | no throw for a config that works today | | #41665 | robobun | taken | | | #41670 | robobun | taken | | | #41674 | robobun | taken | | | #41679 | robobun | reworked | three sentences; `routing.mdx` half not taken | | #41680 | robobun | reworked | never replaces a live context's closures | | #41698 | robobun | reworked | `removeCredentials()`; `fetch` half landed in #42692 | | #41705 | robobun | taken | inside #41674's code | | #41712 | robobun | stays open | product decision | | #41728 | robobun | stays open | not only WebSocket; overlaps in `websockets.mdx` and `error` | | #41811 | robobun | reworked | `upgrade(Request)` only | | #41875 | robobun | taken | plus `headers: {}` and declining a protocol | | #41962 | robobun | taken | | | #42011 | robobun | superseded | upstream's checks, both roles | | #42216 | robobun | reworked | 5 lines, no budgets | | #42318 | robobun | stays open | the libdeflate patch is a vendoring decision; the WebSocket path is deleted, its two tests are kept | | #42443 | deepshekhardas (ext) | taken | | | #42673 | davidhevn (ext) | taken | its two lines; a different fixture, because the lib.dom run fails with the PR's own | | #42974 | robobun | reworked | `resume()` on close; the rest follows from `readyState` | | #42976 | robobun | taken | trimmed | | #42978 | robobun | taken | derived from `readyState` | | #43018 | robobun | reworked | with #43696: one field instead of four | | #43176 | robobun | reworked | these connections use the stream transport; as written, the PR would deliver `head` twice | | #43243 | robobun | reworked | bounded by the byte limit | | #43445 | robobun | taken | | | #43511 | robobun | taken | | | #43614 | robobun | stays open | goes with #43441 | | #43696 | robobun | reworked | the deletion only; no nested-event-loop cases | | #43711 | robobun | reworked | `terminate()` and exit flush; no flag | | #43763 | robobun | reworked | "always buffer"; no `handshake_dispatched` | | #44061 | 1cedsoda (ext) | stays open | RFC 8441 is a separate feature; needs a rebase | | #44111 | robobun | superseded | upstream's `event-target.js`, both roles | | #44112 | robobun | reworked | second native handler set, no per-event flag | | #44122 | robobun | not taken | used its options struct and test table; no `validate()` / `dial()` split | | #44123 | robobun | reworked | real `http.request()`; no deferred native socket | | #44165 | 1cedsoda (ext) | stays open | built on #44061 | | #44255 | robobun | superseded | native Buffer for text | | #44460 | robobun | reworked | binding + `can_upgrade()`; 101 instead of 500 | | #44520 | robobun | reworked | no backpressure limit, JS queue deleted | | #44535 | robobun | reworked | native entries + `fin`, `compress`; no lint | | #44553 | steipete (ext) | superseded | same result, built natively; test kept | | #44554 | steipete (ext) | reworked | public `ServerWebSocket.pause()`; tests that fail against a no-op `pause()`; no 120 s kill | | #44821 | robobun | taken | plus `realign` | | #44822 | robobun | reworked | three small changes instead of five mechanisms | | #44964 | robobun | taken | explicit `Proxy-Authorization` wins | | #45000 | robobun | reworked | reports the error and keeps serving | | #45030 | steipete (ext) | reworked | its sum and tests; plus cork, backpressure, close, `bytesRead`, the 101 | | #45122 | robobun | taken | extended to failures after open, and 1006 | | #45125 | robobun | superseded | falls out of `emit("error")`; two regressions avoided | | #45196 | robobun | reworked | moves the `close` event; no second parser | Issues that can also be closed: - #22870: the client option works; the reporter set it on the server. - #18869: the code in its trace was rewritten by #39642 / #39435, and it has no s…

Jarred-Sumner requested a review from alii as a code owner October 6, 2026 06:16

robobun mentioned this pull request Oct 14, 2026

node:http2: report a peer reset that a client write sees first #42182

Open

This was referenced Oct 14, 2026

WebSocket: real closing handshake, one failure path, ws rewritten on native transports (consolidates the open WebSocket PRs) #45223

Merged

WebSocket client: resume a paused socket when the connection closes #42974

Closed

robobun mentioned this pull request Oct 14, 2026

ws: enforce the client's maxPayload and handshakeTimeout in the native WebSocket client #45243

Open

omarmahamid mentioned this pull request Oct 15, 2026

Idle session pins a CPU core: OTEL socket stuck in a zero-wait send() retry loop (~800K syscalls/s, 0 bytes sent) anthropics/claude-code#102531

Open

Jarred-Sumner mentioned this pull request Oct 16, 2026

sql: consolidate the open Bun.sql, bun:sqlite and node:sqlite pull requests #45304

Merged

steipete mentioned this pull request Oct 16, 2026

chore: sync upstream oven-sh/bun main (2026-10-16) openclaw/bun#177

Merged

This was referenced Oct 16, 2026

test(tls): cover an untrusted chain for a renegotiation request after end() #45534

Open

node:https: build the TLS context in createServer(), serve it from Bun.serve #45535

Open

Remove dead code from helpers.h and MimallocWTFMalloc.h #45548

Open

Kushalkhemka mentioned this pull request Oct 16, 2026

Pi-Bolt 0.9.4: upstream Bun and WebKit fixes opensec-git/Pi-Bolt#50

Merged

robobun mentioned this pull request Oct 16, 2026

ci: add 4 files to the flaky list #41270

Closed

robobun mentioned this pull request Oct 17, 2026

node:tls: reject a dhparam smaller than 1024 bits #45637

Open

This was referenced Oct 17, 2026

fix(sql): TypeError tls must be a boolean or an object + fix SSL/TLS behaviour to match postgres.js standard #26503

Closed

sql: a later close() waits for the pending close, for at most its timeout #43959

Closed

Navigation Menu

Repository navigation

tls: consolidate the open TLS fixes (both engines, node:tls, node:https, WebSocket, SQL) - #44618

tls: consolidate the open TLS fixes (both engines, node:tls, node:https, WebSocket, SQL)#44618
Jarred-Sumner merged 174 commits into
mainfrom
claude/tls-consolidated

Jarred-Sumner commented Oct 6, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Jarred-Sumner commented Oct 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR do?

The ones that matter most

By area

Behavior changes

Worth a look in review

Known limits

Not included

How did you verify your code works?

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Jarred-Sumner commented Oct 6, 2026 •

edited

Loading