Home > front end >  How to stop chrome from upgrading websockets from WS to WSS when the websocket object is created on
How to stop chrome from upgrading websockets from WS to WSS when the websocket object is created on

Time:12-30

I made a real browser port of minecraft here that is multiplayer only, it is based on websockets.

https://g.eags.us/eaglercraft/

I want the game on this page to be able to connect to servers using both the WS and WSS websocket protocol, so buying web SSL certificates is not mandatory for the people who are just trying to set up small private servers to use to play this game on from school computers or something. Both my origin server and cloudflare are currently configured to be strictly HTTPS only and you cannot normally initialize an insecure WS websocket from a secure HTTPS page, meaning anyone trying to play the game on their own server off of my 'official' link will need an SSL certificate and a WSS URI.

I have added the content-security-policy: upgrade-insecure-requests header to the link I posted above. I am under the impression that this enables regular insecure HTTP/WS connections to be made on the page even if the page was loaded via HTTPS but it doesn't appear to work. When I create a WebSocket object in chrome devtools console of this page and tried connecting it to a WS URI, the network tab shows that the actual request used by the object had the WS in the URI replaced with WSS even though the URI I typed was WS.

How do I disable all this behavior for this specific page and just perform the websocket request as-is

CodePudding user response:

I misinterpreted the header's behavior. It was working as advertised, upgrading the URI from WS to WSS. I initially interpreted it as a header that applies a permission override for the browser to just treat all socket URIs as if they had already been upgraded to WSS without actually upgrading the underlying URIs and requests.

Apologies for my 3:00 AM confusion, see the MDN Page for more clarification

  • Related