Adam Rice

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...

We've been looking at this for Chrome. Our tentative plan is to create a new API called WebSocketStream. This avoids confusion over what should happen if you use the new...

See https://github.com/w3ctag/design-reviews/issues/394.

It's an interesting proposal, and I've also considered similar things in the past. I'm concerned this maybe a solution for the wrong problem. Developers want to verify that their application...

I am one of the authors and maintainers of Chrome's WebSocket implementation. I oppose this proposal. Reasons: - The WebSocket handshake security model hinges on exposing no more capabilities for...

@Misiu In the specific case of WebSockets I think passing an authentication token in the URL is okay. The reason is that, unlike HTTP URLs, wss: URLs are never exposed...

@maleta > So my question is, @ricea, do you think that this reported issue is completely irrelevant because of fact that ws/wss urls are never exposed to users? Security measures...

@annevk I think origin policy will probably be implemented in the browser in the same place as CORS, so it would still mean re-wiring the handshake to go down the...

Yes, I think you're right. [Main fetch](https://fetch.spec.whatwg.org/#main-fetch) step 7 sets _response_ to a network error, then step 29 runs "fetch response handover". Then at step 4 of [fetch response handover](https://fetch.spec.whatwg.org/#fetch-finale)...

The difficulty with preflighting auth via XHR or fetch is that the pywebsocket API doesn't support basic auth for plain HTTP except by restarting it with different command-line arguments. I...