add binaryType property to websockets

[anonrig]

No description provided.

[ask-bonk]

Adds binaryType property to WebSocket per WHATWG spec, gated behind the websocket_standard_binary_type compat flag.

Findings (ranked by severity):

1. [HIGH] Missing binaryType_ override in fetch() upgrade path — http.c++:1562 creates a WebSocket via js.alloc<WebSocket>(kj::mv(webSocket)) without applying the compat flag override. A worker doing const resp = await fetch(url, {headers: {Upgrade: 'websocket'}}); resp.webSocket.accept(); would get binaryType === "arraybuffer" even with the flag enabled, and binary messages would be delivered as ArrayBuffer instead of Blob.

2. [MEDIUM] Redundant binaryType_ initialization — The hibernation constructor (WebSocket(jsg::Lock&, IoContext&, kj::WebSocket&, HibernationPackage)) correctly reads the compat flag, but WebSocket::constructor() and WebSocketPair::constructor() set it after allocation. This is fragile — every new call site must remember to add the override. Consider adding jsg::Lock& to the WebSocket(kj::String url) and WebSocket(kj::Own<kj::WebSocket>) constructors so the default can be set once.

3. [LOW] Hibernatable WebSocket message path unaffected — The sendHibernatableWebSocketMessage() path in global-scope.c++:644 passes kj::OneOf<kj::String, kj::Array<byte>> directly to the webSocketMessage() handler (always ArrayBuffer). This is by design for the DO handler API, but worth noting that binaryType has no effect on the hibernatable path. Consider documenting this in the compat flag description or in code comments.

---

This review was generated by an AI assistant and may contain inaccuracies. Please verify all suggestions independently.

[ask-bonk]

I'm Bonk, and I've done a quick review of your PR.

Summary: Adds the WHATWG-spec binaryType property to WebSocket, defaulting to "blob" behind a new websocket_standard_binary_type compat flag (ordinal @165, enable date 2026-03-17). Binary messages are delivered as Blob when binaryType === "blob", ArrayBuffer when "arraybuffer".

Findings posted to the PR (ranked by severity):

1. [HIGH] Missing binaryType_ override in fetch() upgrade path — http.c++:1562 creates a WebSocket via js.alloc<WebSocket>(kj::mv(webSocket)) without applying the compat flag. Workers using fetch() with WebSocket upgrade will get binaryType === "arraybuffer" even with the flag enabled, and binary messages will be delivered as ArrayBuffer instead of Blob.

2. [MEDIUM] Fragile post-allocation override pattern — Three call sites (constructor(), WebSocketPair::constructor(), and the missed http.c++ one) must independently remember to set binaryType_ after js.alloc<WebSocket>(). The hibernation constructor does it correctly inline. Consider moving the compat flag check into the constructors themselves to prevent future misses.

3. [LOW] Hibernatable WebSocket message path unaffected — sendHibernatableWebSocketMessage() passes binary data directly to the webSocketMessage() handler as ArrayBuffer regardless of binaryType. This is by design for the DO handler API but worth documenting.

Review posted at: #6178 (review)

github run

[codspeed-hq]

Merging this PR will not alter performance

✅ 70 untouched benchmarks
⏩ 129 skipped benchmarks¹

---

_{Comparing yagiz/add-binaryType-websocket (0d3eac6) with main (686673f)}

Footnotes

1. 129 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩