PS: I have cleared all entries from my Firefox history which contain `https://example.com` and then restarted firefox. This did not fix the problem.

If I use the IP address of `example.com` instead of the domain name, this unwanted redirection does not occur. It only happens when I explicitly enter `http://example.com` and not `http://aaa.bbb.ccc.ddd`, where `aaa.bbb.ccc.ddd` is the IP address of `example.com`.

It appears that Firefox is trying to be "helpful" and changing `http://example.com` to `https://example.com` because I created that redirection for a short time on my web server.

Be clear that this is ***not*** helpful to me in the least, and it simply makes my life worse. If this is the result of some sort of Firefox feature, I would very much like this feature to be disabled, or at least fixed.

Thank you.

PPS: I found this: https://stackoverflow.com/questions/30532471/firefox-redirects-to-https

It seems like Firefox is indeed trying to "help" me by means of HSTS. I understand how it might be useful and more secure to redirect any `http` site to its `https` counterpart, if the `https` counterpart actually exists. But in this case, the `https` counterpart only used to exist and does not exist any more, but Firefox is incorrectly still trying to perform this redirection.

It seems like Firefox is performing a kindergarten-level approximation of HSTS ... i.e., always rewriting an `http` URL to its corresponding `https` URL, without checking whether the `https` URL is still in existence. This seems to simply be lazy programming.

How can I disable this unwanted behavior? Unless there is a way to fix this, I am going to abandon Firefox.

PPPS: OK, one last PS.

I found a workaround. See the final answer in this discussion: https://security.stackexchange.com/questions/102279/can-hsts-be-disabled-in-firefox

It's a major pain to have to manually edit `SiteSecurityServiceState.txt` whenever I want to fix something like this. I know when I make changes to the web sites that I manage myself through my nginx server, but there are millions of web servers in the world, and anyone could make a similar change to a site, and then all the Firefox instances all over the world will no longer be able to access the original `http` URL.

In other words, Firefox should be smart enough to test for an `https` site's existence before performing this URL rewrite. As I stated above, the lack of such a test is nothing more than lazy programming.

Another solution could be that these HSTS entries get set up to expire after a very short time.

In any case, either this gets fixed very soon by the Firefox developers, or I abandon that browser.

I'm not marking this as a solution, because I don't consider any solution to exist until the Firefox developers fix this.

Since no one can actually get to your site nor a matching site with the same issue it be hard for anyone to know what is happening without seeing it happen.

Thank you for your reply, WestEnd. But as you can see from my follow-up messages, I figured out the cause of the issue and described a less-than-desirable workaround.

For anyone who manages a web server, here is how to duplicate the issue:

(1) Create an http-based web site, for example, `http://example.com`. (2) Access that site a few times via version 62.0.2 of Firefox on your desktop machine. (3) Create a corresponding https web site, for example, `https://example.com`. (4) Access that https site a few times via Firefox. (5) Access the original http site a few times via Firefox. The browser should redirect these http accesses to `https://example.com`. (6) Now, completely remove the https web site from the web server. In this example, the web server is back in the state described after step 1, above, and no `https://example.com` site exists any more. (7) Restart the web server, and reboot your desktop machine. (8) Go back to Firefox and try to access `http://example.com`. The browser will rewrite the URL as `https://example.com`, and the access will fail, because that https web site no longer exists. (9) Repeat step 8 over and over during the course of a couple days. The incorrect URL rewriting will continue.

In my comments above, I explain how I discovered that this is a "feature" of Firefox, because of their faultly implementation of HSTS. And I also describe a hacky, undesirable way to work around this issue by manually editing Firefox's `SiteSecurityServiceState.txt` file.

Hello Hippo Man, Yes you are correct. And your less than desirable workaround may be good for testing purposed. But in the real world the trend is that all sites may provide a secured connection. Its better for security, for trust and for SEO ... So that if you are a site owner ask your provider to secure your site If you are on localhost or localtest.me you can generate a self-signed certificate for testing purposes. using ssl. Thank you for your detailed answer to your own question. Have a good day !

Thank you, AnnaSycamore.

I understand the current trend of forcing https via the use of HSTS. The problem is this (I mentioned this above, and I will repeat here for clarity) ...

There are millions of web servers all over the world. If anyone creates an http site and a corresponding https site, but for whatever reason decides not to keep the https site alive ... either temporarily or permanently, there are also millions of Firefox users who will never be able to get to the original http site again if they have ever visited that site before. Every access to the http URL will be rewritten as an https access that will fail ... unless each of these these millions of Firefox users manually edit the `SiteSecurityServiceState.txt` file.

All Firefox needs to do is check for the existence of any https URL rewrite target before actually performing that rewrite. If the https site no longer exists, accessing the original http site should not ever cause the failing rewrite to be performed.

I know that HSTS is also implemented within Chrome. That browser does not fail in this manner. They apparently handle this case correctly, and they refrain from rewriting http accesses to the previously accessed and HSTS-registered https site if that https site has now disappeared.

I'm a software developer and have been one for years, and I know that putting a little extra code into Firefox's HSTS module to handle this case would be a very simple thing to do.

One way this could be handled is as follows:

1. A user accesses an http site which previously had an associated https site which was registered via HSTS, but the https version of the site has now disappeared. 2. Firefox redirects the http request to the corresponding https request, as it does now. 3. The https request fails because that https web site no longer exists. 4. The following is new, proposed functionality: Firefox knows that the failed https access is the result of an HSTS rewrite, so Firefox pops up a dialog box which informs the user that the https site which corresponds to the originally entered http site has disappeared, and it gives the user the option to either (A) get rid of the HSTS entry for that site, or (B) continue to receive errors whenever the http site is accessed.

In fact, I'm willing to sign a non-disclosure agreement and write that kind of code myself, and I would donate it for free to the Firefox developers.

FYI: In addition to correctly handing the case I described above, Chrome also provides a method for its users to remove HSTS entries. This is still a bit of a pain for the user, but it's much more convenient than Firefox's method. See the "How to Delete HSTS Settings in Chrome" section in this discussion ...

https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/

Actually, that same web site I mentioned above describes a way to get rid of any given site's HSTS entry in Firefox by means of the "Forget about this site" option within the history list.

However, that method is described as not being reliable, and that is also my experience: it did not work for me.

Perhaps all that the Firefox developers need to do is fix the "Forget about this site" option so that it works properly.