Closed Bug 1433933 Opened 7 years ago Closed 5 years ago

Firefox doesn't handle *.localhost domains (loopback)

Categories

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

58 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1220810

People

(Reporter: thomas, Assigned: jkt)

References

Details

(Whiteboard: [necko-triaged])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 Steps to reproduce: Run a server that listens to "test.localhost" and open "test.localhost" in firefox Actual results: If `browser.fixup.alternate.enabled` is true it changes the URL to "www.test.localhost". If it's disabled it shows the default "We’re having trouble finding that site." error message. Expected results: The site "test.localhost" should be loaded. The ".localhost" TLD should be a loopback interface which works correctly in Chromium. See https://en.wikipedia.org/wiki/.localhost
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Component: Networking: HTTP → Networking: DNS
Not sure this valid.
Assignee: nobody → daniel
Priority: -- → P3
Whiteboard: [necko-triaged]
I have the same problem on Firefox 58.0.2 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0) Gecko/20100101 Firefox/58.0) and in my case this is blocking from using Firefox with local dev servers since. Previously, I have used *.dev but due to HSTS is now unusable and *.localhost is throwing 404.
This is not technically a bug, since RFC 6761 specify that "Application software MAY recognize localhost names as special, or MAY pass them to name resolution APIs as they would for other domain names." Nevertheless, DNS servers themselves should always respond with 127.0.0.1, and users may assume it is always 127.0.0.1. In practice, this doesn't happen yet, so fixing it on the browsers might be a better option. Chromium already supports it, and I would argue it's easier (and saner) to update ones browser (if you're doing local development) than to update a bunch of DNS servers. https://tools.ietf.org/html/rfc6761
This his ripple effects for allowing mixed content localhost requests. Since Firefox currently does a DNS lookup for everything, localhost (and domains) are not considered trustworthy (see https://w3c.github.io/webappsec-secure-contexts/#localhost). If Firefox treats localhost and *.localhost domains as special (i.e. not doing a DNS lookup and always using the loopback address), then they can be considered trustworthy. This would allow http://localhost/* queries in a mixed content page. Currently this is blocked and only http://127.0.0.1/* is allowed (see bug 903966).
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Do you guys have an idea how to workaround this problem.
Assignee: daniel → nobody
Status: ASSIGNED → NEW

I just tested current state of this issue:

Chrome 78 already handles *.localhost domains and marks them as Secure Context.
Firefox 69 marks localhost as Secure Context, but does not do the same for subdomains (marks foo.bar.localhost as insecure).
Demo: https://ipfs.io/ipfs/bafybeifnnjo5dyw63fcg6o72jbksrn726hpilqgokdgm44al2v5oxmv2yu/localhost-subdomains

Fully agree with https://bugzilla.mozilla.org/show_bug.cgi?id=1433933#c3, and https://bugzilla.mozilla.org/show_bug.cgi?id=1433933#c4:
it's easier to update Firefox to match Chromium behaviour (and bind to 127.0.0.1/::1) than to rely on set up of custom DNS servers or HTTP proxies.

The use case I am interested in are HTTP Gateways for DWEB protocols, such as IPFS.
Having localhost subdomains working reliable in Firefox (as Secure Contexts) would enable IPFS project to provide Origin-based isolation of websites loaded from local HTTP Gateway (https://github.com/ipfs/in-web-browsers/issues/109 & https://github.com/ipfs/in-web-browsers/issues/89)

Assignee: ehsan → nobody

The uploaded patch in Bug 1220810 is attempting to address this also.

Assignee: nobody → jkt
Status: NEW → ASSIGNED

on Mac:
go to terminal
$ sudo nano /etc/localhosts

on Windows:
Click Start > All Programs > Accessories
Right-click Notepad and select Run as administrator.
In the File name field, type C:\Windows\System32\Drivers\etc\hosts.
click open

then
add aline at the end of the file your domain in front of 127.0.0.1 like the below:
127.0.0.1 yourDomain.localhost

save and exit.

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.