This is strange, I was developing a website today and it didn't redirect me.

Try to go to menu ≡ -> Settings -> Privacy & Security, then scroll down to the HTTPS-Only Mode. Then select Enable HTTPS-Only Mode in private windows only.

I actually have "Don’t enable HTTPS-Only Mode" selected (the third option). Below that there is some text "Firefox may still upgrade some connectionsLearn more" with a link to https://support.mozilla.org/en-US/kb/https-upgrades?as=u&utm_source=inproduct#firefox:win10:fx137&mobile::m136 which does not explain how to turn this behaviour off when I have explicitly tried to browse to an http rather than an https version of a site.

If I set "Enable HTTPS-Only Mode in private windows only" (the second option) what I get is even more bizarre.

An attempt to connect to http://example.com:80 in a non-private browser still results in the URL bar showing https://example.com .

An attempt to connect to http://example.com:80 in a private browser also results in the URL bar showing https://example.com , but a message is displayed saying "Secure Site Not Available".

For the avoidance of doubt - I am trying to use Firefox to test whether or not a particular port is open, and (assuming a web page is being served on that port) display that web page using whatever protocol I requested (http if I typed in http://example.com , https if I typed in https://example.com ). What settings do I need to change so that Firefox simply does what I asked it to do?

1. Clear Cache and Cookies:

   Sometimes, cached data can cause redirection issues. To clear your cache and cookies:
       Click on the menu button (three horizontal lines) in the top right corner.
       Go to Settings (or Options).
       Select Privacy & Security.
       Under "Cookies and Site Data," click on Clear Data.
       Select both "Cookies and Site Data" and "Cached Web Content," then click Clear.

2. Check HSTS Settings:

   If the site has previously been accessed over HTTPS, it may have set an HSTS policy, which forces browsers to use HTTPS. You can check and remove HSTS settings for a specific site:
       Type about:preferences#privacy in the address bar and press Enter.
       Scroll down to the "Certificates" section and click on View Certificates.
       Go to the Servers tab and look for the site in question. If it’s listed, you can remove it.

3. Use a Different Browser:

   If you need to access the site without redirection, you can try using a different browser (like Chrome or Edge) to see if the same behavior occurs.

4. Use a Private Window:

   While you mentioned you've tried a private browsing window, ensure that you are not logged into any accounts that might influence the behavior. Private windows should not use cached data, but if you have previously accessed the site, it may still redirect.

5. Disable HTTPS-Only Mode:

   Firefox has a feature that can force HTTPS connections. To check if this is enabled:
       Go to Settings > Privacy & Security.
       Scroll down to the "HTTPS-Only Mode" section and ensure that it is set to "Don’t enable HTTPS-Only Mode."

6. Try a Different URL Format:

   Sometimes, explicitly specifying the port can help. Try using the following format:

Code

   http://example.com:80/

   Ensure there are no typos or extra characters in the URL.

7. Check for Redirects in Developer Tools:

   You can use the Developer Tools to see if there are any redirects happening:
       Right-click on the page and select Inspect or press Ctrl + Shift + I (or Cmd + Option + I on Mac).
       Go to the Network tab and reload the page. Look for any requests that show a redirect status (like 301 or 302).

8. Modify Hosts File (Advanced):

   If you have control over the server and want to test it locally, you can modify your hosts file to point example.com to a specific IP address. This is more advanced and should be done with caution.

Whilst that last reply is clearly just a copy and paste done without actually reading the question, perhaps it is worth replying to those points:

1. Clear Cache and Cookies: Whilst that clearly doesn't (or at least shouldn't!) apply to private windows (I mentioned above that I tried both) it is worth clarifying _what_ Firefox remembers about a particular site (and I don't mean content here - I mean "how to connect" - HSTS etc.).

2. Check HSTS Settings: In there I only see explicit exceptions that I have added, none for the site in question here and none for any other sites, including those that set "strict-transport-security".

3. Use a Different Browser: Obviously an option, but not an answer to the question, which was not "how do I view some web page" but "how do I make Firefox work differently.

4. Use a Private Window: For the avoidance of doubt - yes it was a new private window; I ensured that no others were open before opening a new one testing.

5. Disable HTTPS-Only Mode: As I already mentioned, this option was already set. My previous reply notes the rather odd effect of "Enable HTTPS-Only Mode in private windows only" (the middle option).

6. Try a Different URL Format: I'd already noted above that I was explicitly specifying the port, and my goal was to "see if anything is active on port 80", so this advice doesn't directly help.

For completeness, I was able to check with other tools and confirm that at the time there was no web server active on port 80. Due to iptables routing, the port _was_ open (i.e. "telnet example.com 80" did not just time out).

Interestingly, however, I note that "Firefox's unexpected redirection behaviour" does not occur on the ports that I tried other than 80, so "http://example.com:8080" does not redirect to some other port, but "http://example.com:80" does.

7. Check for Redirects in Developer Tools: There are no redirects. The websites that I was testing with were just the "welcome" page of the relevant target webserver.

8. Modify Hosts File (Advanced): No, that's not going to help - the DNS servers that my PC has access to all have the correct name(s) in them.

To reiterate - what I am asking is how do I make the option "Don’t enable HTTPS-Only Mode" actually work?

There are a bunch of other "Firefox does not navigate to the page that I tell it to go to" issues listed at "see also", going back over 10 years, and as I mentioned earlier that's the reason why I phrased this question as I did.

For completeness - this is not an HSTS issue. Where there are https sites that Firefox has redirected to in error, those sites have been signed with Letsencrypt or ZeroSSL 90-day "free" certificates.

   curl -s -D- https://example.com | grep -i -E '^strict'

does not return anything like:

   strict-transport-security: max-age=31536000; includeSubDomains; preload

There are a bunch of other "Firefox does not navigate to the page that I tell it to go to" issues listed at "see also", going back over 10 years, and as I mentioned earlier that's the reason why I phrased this question as I did.

For completeness - this is not an HSTS issue. Where there are https sites that Firefox has redirected to in error, those sites have been signed with Letsencrypt or ZeroSSL 90-day "free" certificates.

   curl -s -D- https://example.com | grep -i -E '^strict'

does not return anything like:

   strict-transport-security: max-age=31536000; includeSubDomains; preload

Since port 80 is the default port for HTTP, I don't think specifying port 80 with the http:// protocol affects what Firefox does here.

Contrary to the above discussion, I don't think HSTS instructions are stored in certificates (that seems like a ChatGPT hallucination). They are applied either because of a match with a site on the pre-load list, or a previously saved instruction from the server.

I assume it's not your server if this issue only happens in Firefox. If you need to disable the pre-load list for testing, here's how:

(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button accepting the risk.

More info on about:config: Configuration Editor for Firefox. The moderators would like us to remind you that changes made through this back door aren't fully supported and aren't guaranteed to continue working in the future.

(2) In the search box in the page, type or paste preloadlist and pause while the list is filtered

(3) Double-click the network.stricttransportsecurity.preloadlist preference to switch the value from true to false

The article you linked mentions HTTPS First without mentioning how to modify that. In about:config, you could look at the preferences matching this filter --

dom.security.https_first

-- and toggle them to false for testing (they become bold when they have a non-default value, so it's easy to see what you may want to toggle back after testing).

Thanks for that. Because of the certificates involved, I don't think that it's an HSTS issue, but for testing I set "network.stricttransportsecurity.preloadlist" to false (it had previously been set to "true", the default). I also set "dom.security.https_first" to "false". It, and the other "dom.security.https_first" settings, were also set to the defaults.

To make reproduction easier I added a DNS entry unrelated to the server where I first saw the problem but does demonstrate it - "nothing.atownsend.org.uk". That is pointing at a reserved but unallocated IPV4 address so it is expected that nothing will ever reply there on any port. There is no IPV6 address corresponding to that name. For this test today I'm using the "mozilla0deb - 1.0" 137.0.1 64.bit build of Firefox on Linux (previous tests by me were Windows).

With those two about.config entries changed, in both a normal and a private window, when I try and browse to http://nothing.atownsend.org.uk:80 , the entry in the URL bar changes to https://nothing.atownsend.org.uk/ and "Firefox can’t establish a connection to the server at nothing.atownsend.org.uk" is displayed - it is not communicated to me whether it ever actually tried port 80 at all.

It looks as if the "Firefox may still upgrade some connections" warning below the "Don’t enable HTTPS-Only Mode" still applies to changing the setting via about:config as well as via "settings"?

To make reproduction easier I added a DNS entry unrelated to the server where I first saw the problem but does demonstrate it - "nothing.atownsend.org.uk". That is pointing at a reserved but unallocated IPV4 address so it is expected that nothing will ever reply there on any port. There is no IPV6 address corresponding to that name.

Oh, I thought you were expecting a response on port 80. So the questions are:

(1) Is Firefox trying port 80 first?

In theory you could use HTTP logging to watch this (although I find the logs generate too large a haystack to find the needle in many cases). https://firefox-source-docs.mozilla.org/networking/http/logging.html

(2) If Firefox is trying port 80 first, why does Firefox then try port 443 rather than simply reporting that the server did not respond on port 80? (And is there a preference to control that?)

> Oh, I thought you were expecting a response on port 80.

Well I was - I was trying to use Firefox to test that I had set that up successfully. It turns out that I hadn't, and no response did come back on port 80.

> In theory you could use HTTP logging to watch this

Yes - that works, in that it seems to show that Firefox is accessing both port 80 (which I requested) and port 443 (which I did not).

> why does Firefox then try port 443 rather than simply reporting that the server did not respond on port 80? (And is there a preference to control that?)

Yes - that is indeed the question!