Configure credentials of cookies for WebSocket

[regseb]

Proposal

Add an option to WebSocket to configure the sending of cookies in the HTTP handshake with the same behavior as the credentials option of fetch.

API

The WebSocket constructor could take an init parameter: new WebSocket (input, init = {}) which would contain the :

• protocols: Either a single protocol string or an array of protocol strings.
• credentials: The request credentials you want to use for the request: omit, same-origin, or include.
• and maybe other options such as the init parameter of fetch.

Other languages

Clients in other languages allow you to directly modify the request headers (and thus the cookies).

• Node.js: ws, websocket
• Deno: WebSocketStream (since v1.18)
• Rust: websocket
• Java: spring-websocket

fetch doesn't allow you to modify the cookies (probably security related), that's why I propose to add the credentials option.

Motivation

I develop a webextension that connects to a WebSocket server. The server doesn't accept requests bigger than 1024 bytes. But other services that are on the same domain name (with different ports), set cookies that are sent unnecessarily to the WebSocket and increase the size of the request. I would like to add the option { credentials: "omit" } to not send cookies.

And if options are useful for fetch, they should be useful for WebSocket HTTP handshake.

Related links

• whatwg/html#6896
• whatwg/websockets#16
• ricea/websocketstream-explainer#3
• Question to disable cookies in WebSocket: https://stackoverflow.com/q/27983153

[annevk]

cc @ricea

[ricea]

Since we broke WebSockets by adding credentials, it's attractive to have a feature to unbreak them by taking the credentials out. But I'm worried about feature creep.

This is the first time I've heard the feature requested, and there's an easy workaround of using a different hostname for the WebSocket server.

I'm on the fence about this. If other vendors were enthusiastic, I could gain implementation experience by adding it to WebSocketStream first.

And if options are useful for fetch, they should be useful for WebSocket.

I disagree. A WebSocket is not an HTTP request, it's a different protocol which uses an HTTP handshake.

Also, some fetch options are nonsensical when applied to the WebSocket handshake. What would keepalive mean?

[regseb]

The proposed API doesn't break the compatible and allows to add other options. But I only ask for the { crendentials: "omit" } option because I don't know enough about the HTTP and WebSocket standard to know which fetch() option can be added in WebSocket.

For the workaround, I don't have a handle on the server. My WebExtension connects to the Kodi media center which is often installed on a server in the local network. Kodi already provides several services and users can also install other programs on the server. 😕

[davidfowl]

I think this is the issue to fix whatwg/websockets#16. It's unclear if people are motivated to fix it and I'm still getting complaints about people not wanting to put bearer tokens into query strings...

[annevk]

@davidfowl FWIW, if you convinced the Edge team this (or that issue) is something they should work on that might make a difference. In the end what you need is implementer support.