1679249 - Firefox redirects localhost to HTTPS

Status: UNCONFIRMED

(Core :: Networking: HTTP, defect, P3)

Description

[opensource3]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

Went to a website I own, it kept going to the https:// version despite specifically saying http:// Though this seems to be something with localhost and Firefox's history. Not related to the new feature of attempting to try and go to https sites when available.

Actual results:

I was able to fix it with this fix from stackoverflow 'Firefox redirects localhost to HTTPS' https://stackoverflow.com/a/45408398/4084546
It did however cost me a half night of sleep so, that was unfortunate.

Expected results:

What should have happened is that it automatically discarded the saved version and attempts to connect the right way. Chrome does not have this problem. That was how I diagnosed there was a problem with the website.

Comment 1

[Andrei Purice]

Setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

Comment 3

[maunakai]

The fix from stackoverflow did not work for me!!!

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
I have Laragon install in my windows 64bits v.1909 and I could not access anymore to http://127.0.0.1 (Chrome can !!!)
Firefox Developer Edition v85.0b9

Actual results:
http://127.0.0.1 is redirect to https://127.0.0.1 givin a "The Connexion Failed"
Even if I modify browser.fixup.fallback-to-https to false I have no redirection but 127.0.0.1 still failed but if I try http://localhost it is working !!!

Comment 4

[edera]

Use case: launch a Pluto.jl instance inside a separated browser (to debug crashes)

firefox -new-instance -P Pluto http://127.0.0.1:1237

Mozilla Firefox 78.10.0esr, shipped with openSUSE Leap-15.2.

Even with

browser.urlbar.autofill => false
network.stricttransportsecurity.preloadlist => false
browser.fixup.fallback-to-https => false

After a "forget about this site", it works once.
But subsequent calls timeout again.
This happens equally with 127.0.0.1 and localhost.

Comment 5

[edera]

The Pluto profile was brand new, no extension.
By the way, --safe-mode does not help.

Launching in a private window works.

firefox -new-instance -P Pluto --private-window http://localhost:1237

Comment 6

[edward.a.cheney.mil]

I am encountering this same problem. Here are things I have attempted without resolution:

• In about:config I have set these items to false:
  • browser.urlbar.autoFill
  • browser.fixup.fallback-to-https
  • network.stricttransportsecurity.preloadlist
• In dev tools in the network tab you can edit a prior request and resend. I have attempted to edit https://localhost to http://localhost and resent.
• I have completely uninstalled Firefox and all Firefox components. I then downloaded a latest version of Firefox and installed it. The installation recognized cached Firefox data on my harddrive and automatically included this data into the browser's installation without asking.

The result of this problem is that Firefox is permanently dead on the device for test automation. If you start Firefox with the -start-debugging-server flag the browser spawns an HTTP/WS listener on a specified port. If every request to localhost is redirected to HTTPS by the browser you can never reach the browser's service and therefore cannot ever perform test automation again.

Comment 7

[:Gijs (he/him)]

Does removing SiteSecurityServiceState.txt from the profile directory fix the issue?

Comment 8

[edward.a.cheney.mil]

I emptied that file and the defect persists.

Comment 9

[:Gijs (he/him)]

(In reply to edward.a.cheney.mil from comment #8)

I emptied that file and the defect persists.

Did you delete the file after Firefox was closed, and before reopening Firefox?

Does the problem happen in a private window?

The problem will probably go away if you refresh Firefox, as it creates a clean profile and only transfers over history, bookmarks and passwords etc., not internal data - which should 'unbrick' your device for testing purposes. But that is unlikely to tell us why it is broken at the moment...

Comment 10

[edward.a.cheney.mil]

Yes, but just to be sure I did it again. I close all instances of Firefox. I then open the file and delete all contents reducing the file size to 0kb. Firefox is then dynamically opened by my application using command: start firefox -MOZ_LOG_FILE "c:\user\austincheney\drial\lib\logs\firefox" -MOZ_LOG "timestamp,rotate:200,nsSocketTransport:5" -start-debugger-server 9000

Then I open SiteSecurityServiceState.txt back up and here are the complete contents of the file:

firefox.settings.services.mozilla.com:HSTS 0 18831 1658605364064,1,0,2
incoming.telemetry.mozilla.org:HSTS 0 18831 1642837374262,1,0,2
contile.services.mozilla.com:HSTS 0 18831 1658605364412,1,0,2
img-getpocket.cdn.mozilla.net:HSTS 0 18831 1690141364466,1,1,2

This problem does occur in private mode as well. I cannot seem to make the problem go away.

Comment 11

[edera]

This seems fixed, at least in the Pluto use case in firefox 102.3.0esr shipped with openSUSE 15.4:
localhost:1234 gets translated to http://localhost:1234, and Pluto now opens fine, with just
firefox -P Pluto http://localhost:1234
(the Pluto server has been updated, but since the firefox url is now correct, I'd say the fix comes from firefox, thanks !)