Menu
I'm having trouble opening a websocket in Chrome. It seems that there is some CORS policy in chrome for websockets.
If I am on www.example.com and attempt to open the websocket at api.example.com it'll say pending on the console network tab, and will fire the onerror with a message WebSocket connection to 'wss://api.example.com' failed: Connection closed before receiving a handshake response. If I look at the server I do not see a request for a web socket connection being made, so there is no options request to respond to, or Ability to set an Access-Control-Allow-Origin header.
However if I first make a request to api.example.com which on the browser will redirect me back to www.example.com it'll work fine.
Are you required to use the same origin for websocket requests in chrome?
Note: this issue is only with chrome.
572
Cross-origin restrictions imposed by SOP and CORS policies do not apply to WebSockets because those restrictions are placed on HTTP responses while WebSockets work over WS (WebScoket) or WSS (WebSocketSecure) protocols. To initiate a WebSocket connection, however, the client has to connect to the server over HTTP.
Chrome has a limit of 6 connections per host name, and a max of 10 connections. This essentially means that it can handle 6 requests at a time coming from the same host, and will handle 4 more coming from another host at the same time.
Google does not support WebSocket connections in Googlebot.
There is no browser enforced CORS with WebSocket. Here are 2 things that can go wrong (assuming you use both HTTPS and WSS):
Origin. The Origin HTTP header is set by the browser to the origin of the HTML page containing the JavaScript that is opening the WebSocket connection. A server MAY check that header and deny. But since you say other browsers are working (which?), this is unlikelywss, the server certificate MUST be completely valid, and acceptable to the browser without any user interaction. Is this the case?
172
I came across this issue again. I still haven't figured out why, but making an OPTIONS (or any other) request to the subdomain first allows the connection to be opened.
This only seems to be a problem with wss connections, and has popped up across multiple domains and certificates.
34
This sounds like it has to do with making cross-origin requests that are not "simple". HTTP requests that are not simple are "preflighted" by the browser (Chrome at least) with "OPTIONS" automatically. I'm guessing the browser is just enforcing this behavior.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Simple_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests
1
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
