Bug 160504

Summary: Localhost subdomains don't work
Product: WebKit Reporter: Dave Jeffery <djeffery>
Component: Page LoadingAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: achristensen, ap, beidson, contact, fran, fred.wang, ggaren, jfernandez, jjprevite, lidel, livid, me, mikaela, webkit-bug-importer, youennf
Priority: P2 Keywords: InRadar
Version: Safari 9   
Hardware: Mac   
OS: All   
See Also: https://bugs.webkit.org/show_bug.cgi?id=171934
https://bugs.webkit.org/show_bug.cgi?id=127676
https://bugs.webkit.org/show_bug.cgi?id=232223
https://bugs.webkit.org/show_bug.cgi?id=236049

Description Dave Jeffery 2016-08-03 06:21:29 PDT
Summary:
Localhost subdomains (i.e. 'http://mysite.localhost') don't work in Safari. They work ok in all other web browsers (Chrome, Firefox, Opera etc..).
I am not sure if this is a Safari/OS X issue or a webkit issue, feel free to close this bug report if that is the case.

Steps to Reproduce:
1. Start up a local server that responds to the host header of 'mysite.localhost' on port 8000 (any port is fine)
2. Try to access the site in safari using the url: http://mysite.localhost:8000/

Expected Results:
Every other web browser (Chrome, Firefox, Opera etc..) that I have tested will find the server and load the page as expected. Localhost subdomains don't seem to be mentioned in any official spec but the fact that they work in every other browser means that people use them for real-world development.

Actual Results:
Safari gives the error "Can't find server"

Version:
Tested on OS X 10.10 and OS X 10.11 with Safari 9.1.2.
Comment 1 Irakli Gozalishvili 2020-07-08 11:04:01 PDT
https://tools.ietf.org/html/rfc6761 suggests that "localhost" can be treated specially and should hardcode localhost names to the loopback address:

>  "Application software MAY recognize localhost names as special"

and:

>  "Name resolution APIs and libraries SHOULD recognize localhost
>   names as special and SHOULD always return the IP loopback address
>   for address queries and negative responses for all other query
>   types.  Name resolution APIs SHOULD NOT send queries for
>   localhost names to their configured caching DNS server(s).)."


Chrome already support supports / ships this:
https://bugs.chromium.org/p/chromium/issues/detail?id=510124

And firefox is working on this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1220810

It also appears that some of the web platform tests do test for this and were disabled:
https://bugs.webkit.org/show_bug.cgi?id=161142


Any chance of get Safari to get Safari localhost to loopback address ?
Comment 2 Radar WebKit Bug Importer 2020-10-27 06:49:00 PDT
<rdar://problem/70720358>
Comment 3 Joe Previte 2022-08-01 14:17:54 PDT
This appears to still be an issue in Safari 15.5

To reproduce:
1. `python -m http.server`
2. Navigate to http://anything.localhost:8000/ in Safari
Comment 4 Javier Fernandez 2022-08-17 05:19:46 PDT
This bug doesn't affect the WebKitGtk+ port. At least, the test case described in comment c#3 works as expected in the mentioned WebKit port.
Comment 5 Alexey Proskuryakov 2022-08-20 15:45:45 PDT
This is mostly something to fix in underlying networking libraries. As long as "ping mysite.localhost" doesn't work in Terminal, I wouldn't expect Safari to behave any differently.

WebKit side of this is to make sure that this doesn't let websites work around any security or privacy mitigations we may have around talking to localhost.
Comment 6 Xin Liu 2022-08-20 15:57:02 PDT
If *.localhost can get implemented in the underlying network layer, it would be pretty useful in an IPFS context. Currently, with Chrome, I can access a decentralized website hosted on IPFS + ENS like this:

http://uniswap.eth.ipns.localhost:18181/

http://planetable.eth.ipns.localhost:18181/

In the example above, localhost:18181 is the local IPFS gateway port.

It would be awesome if it could work in Safari too.
Comment 7 Javier Fernandez 2022-08-31 15:00:06 PDT
Not only Chrome, but Firefox and any WebKitGtk+ port browser are able to access localhost subdomain (like the test case in comment #3). 

Since Safari is the only one behaving differently, would it make sense to fix this in the Networking layer for the shake of ensuring browser interoperability ?