What to do with WebSockets

[joelweinberger]

I think we've discussed before that WebSockets should simply be disallowed. If that's the case, that should be explicitly added to the spec. If not, I assume we'll need to add Suborigin headers to requests. Either way, we need to spec out a solution.

[annevk]

Since you can polyfill WebSockets fairly soon, disallowing might be okay.

[kentonv]

For the Sandstorm use case[0], disallowing websockets would be pretty disappointing, as many of our apps use them extensively -- some without any fallback.

[0] https://docs.sandstorm.io/en/latest/administering/wildcard/#why-sandstorm-needs-wildcard-dns

[joelweinberger]

Fair enough. If we disallowed it, I would consider that a temporary measure for v1 until we decided exactly what to do. @kentonv, do you have particular thoughts on how to work them into the spec today? Just put a Suborigin header in the request?

[kentonv]

I'm not very familiar with the spec, but it seems like the right solution is to include a Suborigin header, and for the Origin header to contain the "serialized suborigin value" as with CORS requests.

[devd]

I think WebSockets can also be pretty easily faked using iframe based privilege separation: it sucks but I think for v1 we have to be pretty brutal about getting a MVP out and seeing how developers use it and what are the issues/problems using it. So, I am totally fine with punting it for v1.

[joelweinberger]

Both in the spec and Chrome implementation, we've disabled WebSockets for v1. I'm leaving this issue open, though, and reclassifying it from bug to next-version so we can hopefully re-enable WebSockets in v2.