Allow dictionary as second param in WebSocket constructor #42
Comments
|
It's a sensible extension point and as far as I know compatible with existing practice. But it's hard to motivate it from a browser implementation point of view. In other words, I'm not opposed, but I don't know how I'd justify the work. |
|
understandable, I was hoping it would be minor enough for browser implementers to not mind lol |
|
Bun also allows a dictionary as second parameter for setting custom headers, example here. |
|
it was also suggested in #16 (comment) which I didn't know about |
KhafraDev
added a commit
to KhafraDev/websockets
that referenced
this issue
May 20, 2024
This commit adds an option bag to the WebSocket constructor that allows settings the protocols. This will bring interop between browsers and server environments that already implement this (Bun and Node). Closes: whatwg#42
KhafraDev
added a commit
to KhafraDev/websockets
that referenced
this issue
May 20, 2024
This commit adds an option bag to the WebSocket constructor that allows settings the protocols. This will bring interop between browsers and server environments that already implement this (Bun and Node). Closes: whatwg#42
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This would allow server environments (specifically talking about nodejs/undici) that implement WebSocket some flexibility, for example, to add custom headers, etc. While we could change it on our side, it would be incompatible with other implementations. Similarly, it'll cause type issues with people who use typescript in cross-env packages (ie. nodejs/undici#1943).
Proposed change:
dictionary WebSocketInit { protocols: DOMString or sequence<DOMString> } interface WebSocket : EventTarget { constructor(USVString url, optional (DOMString or sequence<DOMString> or WebSocketInit) options = []);The text was updated successfully, but these errors were encountered: