WebSockets

[ricea]

Not sure what the capabilities of the GET are, and how much control the caller has.

The capabilities of the GET and the control of the caller are basically identical to an <img> tag. There is an additional Sec-WebSocket-Protocol header whose contents are a list of tokens controlled by JavaScript. Credentials are always included.

If we need a prefetch to even consider issuing a request for an <img> tag then we must do the same for a WebSocket request, or it would be a big hole in the protection.

From a protocol purity point of view, a preflight is best, as it avoids making any changes to RFC6455.

However, from an implementation point of view a preflight is a lot of work. Chromium's WebSocket code goes down a completely different route from the CORS code. On the server side, "pure" WebSocket servers that don't implement HTTP are going to have a hard time adding support for a preflight.

Integrating a website with software running locally (eg. Spotify) is a popular use-case for WebSockets, and so the impact of this change would be considerable.

[annevk]

See also #32.

[letitz]

@ricea I believe the CORS implementation has moved in Chromium from Blink to the network stack, but I am not sure whether that happened before or after your comment. Does your point about it being hard to integrate WebSocket code with CORS code still stand?

[ricea]

@letitz Yes, although it may be easier than before.

[letitz]

In #14, @ricea shared that @yutakahirano who wrote the new CORS code in Chromium believes adding preflights for WebSockets should not be as hard as it was when this issue was filed. 🎉

Given the above description of the capabilities of WebSocket handshakes, I believe preflights should be sent ahead of the handshake. The spec should be updated to reflect this.

[letitz]

My latest understanding here is that since websockets use fetch already, there is no spec change needed to support preflights there. If that's indeed the case, then maybe just a paragraph somewhere calling this out is all we need.

[annevk]

That's correct in theory, but since WebSockets does not currently trigger any preflight, we'd want to double check it actually ends up happening for this.

[ricea]

So it appears that the work remaining to integrate with WebSockets is mostly non-spec work, ie.

1. Modify pywebsocket to support preflights
2. Add web platform tests to verify that the preflight happens and its result is respected
3. Push the ecosystem to handle preflights on WebSocket connections

Would it be appropriate to open an issue on the WebSocket spec repository to track this work?

[annevk]

If Local Network Access is the forcing function it should track completion, probably in this issue. If it helps to have a delegated issue on whatwg/websockets that seems fine though.

(Presumably this would also give us a path towards supporting some features people have requested from WebSockets, such as custom headers.)