Add WebSocketInit dictionary as option for second param in constructor

[christhompson]

Adds the option for using a WebSocketInit dictionary as the second param in the WebSocket constructor. This updates the non-normative description of how the constructor works, and adds steps to the constructor processing algorithm to handle the case where the second param is a WebSocketInit dictionary (extracting the "protocols" field if present).

Fixes #42

• At least two implementers are interested (and none opposed):
  • Chromium (crbug.com/517413738)
  • WebKit
  • (NodeJS/Bun/Deno (as raised on Issue Allow dictionary as second param in WebSocket constructor #42))
• Tests are written and can be reviewed and commented upon at:
  • WPTs are written as part of the draft Chromium implementation crrev.com/c/8197225
• Implementation bugs are filed:
  • Chromium: crbug.com/517413738
  • Gecko: …
  • WebKit: …
  • Deno: …
• MDN issue is filed: …
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[ricea]

Looks minimal and good. I'm holding off on approval only because it's been so long since I've used Bikeshed I don't trust my eyes.

[annevk]

Suggested change

	1. Let |protocols| be an empty sequence.
	1. Let |protocols| be « ».

[annevk]

Maybe using a lambda would be clearer here.

1. Let protocols be the return value of running these steps:
   1. If protocolsOrOptions is a dictionary, then return protocolsOrOptions["protocols"].
   2. If protocolsOrOptions is a string, then return « protocolsOrOptions ».
   3. Return protocolsOrOptions.

[ricea]

This change might not be web-compatible. I am currently investigating.

It turns out that new WebSocket(url, undefined, {}) is a pattern used in some web applications. I don't yet know how common it is. The popular ws Node.js WebSocket library takes a third-argument with an options bag. I have seen code like

new WebSocket(url, undefined, isNodeJS() ? { headers } : {});

in the wild.

Before this change, the above constructor call behaves like new WebSocket(url, "undefined"). If the server response headers include Sec-WebSocket-Protocol: undefined it will work.

After this change, the above constructor call behaves like new WebSocket(url, {}), which is functionally equivalent to new WebSocket(url). If the server response headers include Sec-WebSocket-Protocol: undefined it will fail the handshake due to the subprotocol mismatch.

Without actually trying it, I don't know whether servers will stop returning Sec-WebSocket-Protocol: undefined if clients stop requesting it, or continue to send it and fail.

[annevk]

Seems worth measuring. We could special case undefined, but that seems rather undesirable.