So, suppose you're trying to view the local web server, on a remote machine, that's viewable only locally & only over a certain port (say, 8000). The best way to do this is to use SSH port forwarding, to make the remote server's port available locally. BUT if you do things in the wrong order (if you do port-forwarding, and then view the URL before the remote HTTP server is started), then Firefox autocorrects "localhost:[port]" to "www.localhost.com:[port]"! STR: 1. [optional] Type or paste "localhost:8000" into your URL bar & hit enter. --> "Unable to connect" error page; URL bar still shows "localhost:8000" 2. Use SSH port forwarding to forward port 8000 (or any port) to a SSH server: e.g. "ssh -L 8000:localhost:8000 people.mozilla.org" 3. In a new tab, repeat step 1. (Type or paste localhost:8000 into your URL bar & hit enter.) ACTUAL RESULTS: The URL in my URL bar changes to "www.localhost.com:8000"!!! (Note the "www" and ".com") EXPECTED RESULTS: No autocorrection to "www.localhost.com". My URL bar should still say "localhost:8000" Fortunately, http://www.localhost.com/ is not hosting a web server on port 8000, so I get a "server not found" page. But if "localhost.com" were owned by someone sneaky, they could use this bug to their advantage -- e.g. hosting ads or pop-ups or whatever on www.localhost.com:[EVERY PORT], and whenever some sysadmin inadvertently triggered this bug by performing something like the STR, they'd end up looking at mr. localhost.com's ads.

This is not a recent regression -- I can reproduce in builds going back as far as 2012-06-22. (I can't test builds a few months older than that, because they startup-crash on my machine, I think because they require an older version of some library or something.)

Generally, we autocorrect foo to www.foo.com if we don't do a search. We never do a search if there's a path or port. There are two solutions here, that I can see: 1) don't (ever) do domain guessing for things with ports 2) don't (ever) do domain guessing for localhost Either will fix this bug. I'm inclined to go with 1 to start with, although we could also do both...

This is still an issue.

Ah ok, thanks for helping clear this up. "localhost" by itself seems to be fine, it's only when you specify a port e.g. "localhost:808" that things seem to get all wacky. I'll file a separate bug!

This bug might be more subtle than that - perhaps relating to a previous site that had the same IP, and that had a redirect to the www site. See this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1228574 It's been present in Firefox for several years now, and I thought it's time to report it too...

This happens when I type: http://localhost (including the http - showing that I know exactly where I'm going). Also just localhost or localhost/. Doesn't need a port or anything. Everything's then going to www.localhost.com. So does really need a bit of a fix.

#1256177 is a duplicate of this bug.

(In reply to github from comment #13) > This happens when I type: http://localhost (including the http - showing > that I know exactly where I'm going). That does not happen for me (with a fresh Firefox profile) -- http://localhost gives me "Unable to connect" (as expected/desired). Maybe in your case, you've got something semi-listening/forwarding on point 80? (So you're hitting the same type of thing as in comment 0, but with the port that happens to be implied by a port-less URL)

Thank you for duping over to the correct bug, when searching I'd used terms like "redirect" rather than "autocorrect". Should nsDefaultURIFixup::MakeAlternateURI(): https://dxr.mozilla.org/mozilla-central/rev/37a5b7f6f101df2eb292b1b6baaf1540c9920e20/docshell/base/nsDefaultURIFixup.cpp#526-611 ...use the same "URL-like" regex as maybeCanonizeURL()? (This would fix comment 2's point 1 and also increase consistency between both cases) https://dxr.mozilla.org/mozilla-central/rev/37a5b7f6f101df2eb292b1b6baaf1540c9920e20/browser/base/content/urlbarBindings.xml#644

(In reply to Ed Morley [:emorley] from comment #20) > Thank you for duping over to the correct bug, when searching I'd used terms > like "redirect" rather than "autocorrect". > > Should nsDefaultURIFixup::MakeAlternateURI(): > https://dxr.mozilla.org/mozilla-central/rev/ > 37a5b7f6f101df2eb292b1b6baaf1540c9920e20/docshell/base/nsDefaultURIFixup. > cpp#526-611 > > ...use the same "URL-like" regex as maybeCanonizeURL()? (This would fix > comment 2's point 1 and also increase consistency between both cases) > https://dxr.mozilla.org/mozilla-central/rev/ > 37a5b7f6f101df2eb292b1b6baaf1540c9920e20/browser/base/content/urlbarBindings. > xml#644 makeAlternateURI gets passed the equivalent of "http://localhost/" or "http://localhost:8080/" as a URI object. Its spec (ie href) would pass that regex, because we will have added the protocol well before that (and we want to do that for the obvious "www.foo.com" without "http://" case - though one could argue we should try to do these 2 things in reverse order, that would require a more significant refactor). Also, I don't think we have a good way to do regexp matching in our C++ code. There's bug 1057531 to move all this code into the frontend proper. For the past ~8 years we've just made do with what we have, nobody has had the cycles and stamina to go rewrite stuff and deal with all the potential fall-out on something as high-traffic as the URL bar (though we've tried to prep this a bit in that the unit test coverage for this stuff is a lot better than it used to be). Anyway, I think the simplest solution is to just check for port and the "localhost" hostname explicitly in that code. I'll put up a patch.

Many thanks for the patch! Should another testcase be added to verify the "non-localhost but has port" case which is also fixed by this patch? For example when using boot2docker/docker-machine, the VM gets its own IP, which people sometimes add to /etc/hosts as a single keyword hostname such as `docker`, which might then be accessed via `docker:8000`.

(In reply to Ed Morley [:emorley] from comment #23) > Many thanks for the patch! > > Should another testcase be added to verify the "non-localhost but has port" > case which is also fixed by this patch? > > For example when using boot2docker/docker-machine, the VM gets its own IP, > which people sometimes add to /etc/hosts as a single keyword hostname such > as `docker`, which might then be accessed via `docker:8000`. Added another testcase for this.

Comment on attachment 8865132 [details] Bug 1087380 - avoid alternate (www....com) URI fixup for localhost and items with ports, https://reviewboard.mozilla.org/r/136790/#review140826 Thank you for fixing this! Canceling review request, because I don't have any ownership over docshell/ or URI-handling code. Not sure who the best reviewer would be here -- perhaps bz?

Comment on attachment 8865132 [details] Bug 1087380 - avoid alternate (www....com) URI fixup for localhost and items with ports, https://reviewboard.mozilla.org/r/136790/#review141220 r=me

Pushed by gijskruitbosch@gmail.com: https://hg.mozilla.org/integration/autoland/rev/fb67d4a85575 avoid alternate (www....com) URI fixup for localhost and items with ports, r=bz

This is working great - many thanks! :-)