Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

How to stop Firefox from changing the URL protocol from wss to https when sending a websocket upgrade HTTP request?

  • 4 respostas
  • 1 has this problem
  • 1 view
  • Last reply by dariour

more options

We are working on an express/react application which is using websockets through https to fetch the data and display it on the front end. The app is working as designed on every browser except Firefox. It turns out that Firefox resolves the Request URL to "https://example.url" instead of sending "wss://example.url", which is the default behavior that works on every other broser. This in turn causes problems on the server during load balancing, and the server simply returns a 404 http error code.

I have already tried editing the about:config page in firefox regarding websockets and urlbars, to no avail. (although that would not count as a solution, since we cannot force our clients to do the same)

Is there a way to disable said behavior on Firefox or force it to use wss?

We are working on an express/react application which is using websockets through https to fetch the data and display it on the front end. The app is working as designed on every browser except Firefox. It turns out that Firefox resolves the Request URL to "https://example.url" instead of sending "wss://example.url", which is the default behavior that works on every other broser. This in turn causes problems on the server during load balancing, and the server simply returns a 404 http error code. I have already tried editing the about:config page in firefox regarding websockets and urlbars, to no avail. (although that would not count as a solution, since we cannot force our clients to do the same) Is there a way to disable said behavior on Firefox or force it to use wss?

All Replies (4)

more options

I see you posted this question on Stackoverflow too.

Does looking at this MDN article and this bug help?

more options

No unfortunately. The issue is similar but not the same. Our problem is that even when we hardcode the URL scheme (the whole URL, actually, there is only one) in our application to "wss://", Firefox automatically converts it to "https://", which is unexpected behavior and it causes app-breaking errors. Other browsers don't do this. Instructions on how to mitigate such behavior, or at least an explanation as to why (and how) Firefox does this would be extremely helpful.

more options

It’s not entirely my cup of tea, but are you using a self-signed certificate on localhost, which is supposed to fail? More on that can be found this bug, this bug, this bug and this bug, possibly providing a workaround.

Additionally, could you define "resolve" in "It turns out that Firefox resolves the Request URL to "https://example.url" instead of sending "wss://example.url"? Does that include entering the wss URL on the address bar?

more options

On localhost we aren't using SSL at all. We are using regular http (and ws) for various reasons.

By "resolve" I mean the following: the web app provides the browser with a hard-coded url which looks like "wss://example.url". Firefox takes that url and changes it to "https://example.url" before sending the request to the server.

I have mentioned that we dont use SSL on localhost. It's important to notice that the same thing happens on localhost also, the only difference is that firefox takes the following url: "ws://example.url" and changes it to "http://example.url" before sending.

On localhost this works because there is no load balancer in the way (which is the point where our application breaks). You can think of it as a firewall that blocks traffic when it sees https in the URL but allows wss (a useful way of thinking about it, although not accurate).

I dont think you can check wss functionality through the address bar since it contains additional headers. (it just returns an error, nothing happens, not even the changing from wss to https)

This seems to be an issue with the way Firefox is inherently setup.