Domain guessing results in incorrect "host not found" errors ("www." and ".com" incorrectly added)




Document Navigation
17 years ago
a year ago


(Reporter: Henrik Gemal, Unassigned)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




17 years ago
if you enter "" in the Location field and press Enter you eventual get
an error message saying:
" could not be found. bla bla."
if you press "Ok" the location field still says: ""

The error message should say "" NOT ""

Build 20010121

Comment 1

17 years ago
Adding to meta bug for error handling
Blocks: 61685

Comment 2

17 years ago
Mozilla automatically tries adding a "www." whenever a second-level domain name 
you type into the location bar doesn't resolve (such as  It 
also does that, erroneously (bug 34943), when you cilck a link to  
(I'm not sure what happens if the second-level domain resolves but the server 
refuses the connection.)

It might be good to state what happened in the error message:
" could not be found (also tried".


17 years ago
Blocks: 63736
This also happens when we get a 301 Moved Permanently error with an invalid
hostname to be moved to.  See bug 68534 for an example.  There we get:

  HTTP/1.1 301 Moved Permanently

There is no such host, so we report that "" was not found. 
Since exists and can be accessed just fine, this is rather
Keywords: correctness


17 years ago
Target Milestone: --- → Future

Comment 4

17 years ago
*** Bug 68534 has been marked as a duplicate of this bug. ***

Comment 5

17 years ago
mass move, v2.
qa to me.
QA Contact: tever → benc

Comment 6

16 years ago
Why does Mozilla try to add "www."? Why does it need to? Wouldn't the easiest
way to fix this simply be to disable the www-adding?

Personally I find the automatic www-thing very annoying. If a machine in a local
network called 'whatever' is down, why would I want Mozilla to try It's a waste of bandwith, and almost all important sites work
without www. anyway.

Comment 7

16 years ago
jonasj: you don't need to make the same "I don't want this feature" comment in
every bug about the feature.

Create a bug that says "I think this feature should be disabled" or "I think
this should be off by default", etc.

Comment 8

16 years ago
benc: It wasn't my intention to spam anyone - sorry about that. I just thought I
would ask whether there was some very good reason not to disable this feature
before I filed a bug on it. I filed bug 115539. Again, sorry about the spam.

Comment 9

16 years ago
I believe fixing bug 115539 will also fix this. Marking dependent on 115539.
Depends on: 115539

Comment 10

16 years ago
.com is also added to dialog. type in 'sdfdsf', mozilla says ''
could not be found. We *REALLY* should be saying:

   sdfdsf,, and could not be found. Please check the
   name and try again

Addition comment #10 has been brought to you by the coalition to stop auto www.
and .com'ing, and by viewers like you.
Summary: "www." incorrectly added to domain in "host not found" error message → "www." and ".com" incorrectly added to host in "host not found" error message

Comment 11

16 years ago
Assignee: neeti → adamlock
Component: Networking → Embedding: Docshell
QA Contact: benc → adamlock

Comment 12

16 years ago
qa to me.
tried to improve summary. feedback requested.
QA Contact: adamlock → benc
Summary: "www." and ".com" incorrectly added to host in "host not found" error message → Domain guessing results in incorrect "host not found" errors ("www." and ".com" incorrectly added)

Comment 13

15 years ago
dupe of bug 95390?

Comment 14

15 years ago
Not likely.

95390 deals with http://noSuchHost/ spawning a key word search when it shouldn't
(whereas noSuchHost should). That problem goes away when you turn off "internet
keywords".  This problem focuses on the logic that would go off and look for and, and the error message
that is displayed when that lookup fails. This problem happens even with
"internet keywords" disabled.

Comment 15

15 years ago
cc: cathleene, relates to user perception of performance

Reset milestone to --, please retriage.

If docshell has very inflexible error reporting, then there is a larger problem
that needs to be addressed, which is how to report back errors after many
different connection attempts have been made.

But on the surface, I think #3 is really on the money. The error should say what
was tried and failed, not just the last error because that is the way Necko and
DocShell report errors.

From a performance aspect, it should say that it searched for both, because if
you don't, then people think our DNS resolution is twice as slow as other
browsers, because we might be querying for records that are uncached on the
local DNS server.

Status shows some aspects of domain guessing's rollover, but not clearly enough
to keep a lot of very smart users (look at the names of the people who are
reporting these bugs!) from getting confused or frustrated.

Target Milestone: Future → ---
*** Bug 90557 has been marked as a duplicate of this bug. ***
*** Bug 195824 has been marked as a duplicate of this bug. ***

Comment 18

15 years ago
Why would Mozilla even search for .com domains with the prefix too? That is 
not at all what the user asked! An errrormessage stating 'sdfdsf,, 
and could not be found. Please check the name and try again' 
would therefore even be more confusing in my opinion.
The browser should not try to be smart in this case, because it would not help 
getting the user anyware.


15 years ago
QA Contact: benc → adamlock

Comment 19

15 years ago
The www. & .com fixup is a feature which can be disabled by a pref. This bug
just covers what the error message should say if the feature is enabled.

Obviously if the user types 'foo' and gets an error that could not
be found it is confusing, however considering the prefs told Mozilla to try I don't believe it is *that* confusing. 

I would like the error to state all the urls, however it would require the
docshell track the list of URLs it has tried up until now for each fixup in
order to present this list to the user. This is why this bug has languished -
the code is significant for such a minor usability win.
Severity: normal → minor


14 years ago
QA Contact: adamlock → benc
*** Bug 290749 has been marked as a duplicate of this bug. ***

Comment 21

12 years ago
this "feature" can be disabled by going to about:config and changing the value of "keywords.enabled" to "false".

is there a proper way to do that from the GUI?

i think this "feature" should be disabled by default and made explicit-only. if a user made a mistake in the address bar, indicate the mistake instead of opening some completely random site.

extremely irritating.

Comment 22

12 years ago
browser.urlbar.matchOnlyTyped I think is the pref you actually want zolba, however, at least in FF on the mac, it doesn't seem to work.

Comment 23

12 years ago
er, duh, as clearly documents, it is browser.alternate.*; which does work. In any case, this isn't keywords.

Comment 24

10 years ago
This results in more problems than "just" an incorrect error message.  If I type "forums.mozillazineorg" (note the missing dot) into the address bar, press enter, then correct my typo and press enter again, I get another "host not found" error because of the "www." that Firefox added.
Duplicate of this bug: 236171
(In reply to comment #24)
> This results in more problems than "just" an incorrect error message.  If I
> type "forums.mozillazineorg" (note the missing dot) into the address bar, press
> enter, then correct my typo and press enter again, I get another "host not
> found" error because of the "www." that Firefox added.

Yeah, I can live with the misleading error personally (well, I rarely actually read the text of the Page Load Error page), but altering what I typed in the location bar (beyond adding the http:// and a trailing slash if necessary) is annoying.
Assignee: adamlock → nobody
QA Contact: benc → docshell
Duplicate of this bug: 541600
Duplicate of this bug: 581678

Comment 29

7 years ago
Let's try to add useful comments here.

I stumbled on this bug while setting up a front-end for my company, I know well what DNS configuration there is at this point, and who's serving which content.

* Reproducable for me on FF3.6.6 and 4.0b2. Distribution binaries (Mandriva) vs manual build does not affect the issue.
* I tried playing with browser.fixup.alternate.* parameters, it does not help.

Let me state also that "simple" tools such as curl, or wget "get the math" done properly ;) chromium 6 handles the case properly.

Looking at "dns or http" packets during FIRST lookup in Firefox:
  8.791980 -> DNS Standard query A
  8.808357 <- DNS Standard query response A xx.yy.xx.yy
  8.814991 -> DNS Standard query A
  8.831450 <- DNS Standard query response, No such name
  8.832966 -> DNS Standard query A
  8.849451 <- DNS Standard query response, No such name
  8.851029 -> DNS Standard query A
  8.859189 <- DNS Standard query response, No such name
  8.861028 -> DNS Standard query A
  8.877304 <- DNS Standard query response, No such name

The IP returned during the first lookup is correct. A http://ip-adress-here in firefox will get the job done.

If I retry LATER, the initial lookup

Comment 30

7 years ago
(sorry, submitted too soon).
If I retry LATER, the initial lookup is not done.
 1) either firefox cached the correct response.
 2) or it might have marked it as "invalid"/unresponsive and skips the lookup?

That's the best information I can provide at the moment. I understand that such bugs can be hard to reproduce; let me know if I can provide more details


7 years ago
Duplicate of this bug: 583634
In summary, none of you want fix-up.

This bug reminds me bug 364667 and bug 402210. Is this removing the fix-up at all, or providing hyperlink(s) instead?
Or the location bar should go back to channel::originalURI, after redirecting?
There are two aspects to the bug: the location bar shouldn't change (beyond the normal addition of "http://" and a slash, and whatever other syntactic things it needs), and the error message shown in the "Server not found" page should list the original hostname and not one with "www." added.

Comment 35

6 years ago
I just now found this when trying to open up:

It has following hosts: has address
Host not found: 3(NXDOMAIN)

And Firefox tries to open up www one and I cannot open up perfectly valid url with Firefox.

So you are telling me that this is minor severity as the fixup.alternate feature can be disabled on about:config? Do you think that's proper way for people fix problems that they cannot open a webpage? I don't think many users will even realize that the problem is in their Firefox, not in their Internet connection or the site is down or something else. 

This is just ridiculous, over a century and it's still broken, even we get new Firefox all the time now. IMO failure to open perfectly valid URL with default settings is at least severity major, or maybe even a critical one.

Comment 36

6 years ago
Ok, maybe this wasn't the best place for that comment, but can't find better. That was written quickly in a little rage. Now it seems that the situation has gone like: lookup failed for some reason at first try, then Firefox tried with www and that also naturally fails. But reports that www as this bug says. 

Then my tinkering with fixup setting didn't do anything but just after that I tried again and Firefox did made a new lookup for and it worked and page was loaded.

So problem probably was just what's on the error message is miss leading and it made me think Firefox is totally broken :) So you could just fix the error message to avoid these kind of situations :D
Duplicate of this bug: 746852

Comment 38

5 years ago
Another example:
Search for in address bar (or other random non-existent domain)
Firefox tries
Firefox tries
Firefox changes address bar to

1) The address entry should not be changed. Network issues may prevent access. Both and can be valid and point to different resources. Firefox should not assume www is correct.

2) The current method (as of FF 13) does not indicate on screen that both hosts were tried. It only indicates that was tried.

3) With the current method, a user may naturally remove the www and retry to request only to get the same error. This gives the impression that Firefox is not able to handle host names that are equivalent to the domain name.

I suggest handling be modified to try entered domain, then www if not specified by the user, then display user requested URL in the address bar. 

Usability and security tracking could be enhanced by indicating all hosts that were attempted in the failure page.
Duplicate of this bug: 764007
Duplicate of this bug: 764388
Duplicate of this bug: 1123071
Duplicate of this bug: 317056

Comment 43

3 years ago
I've been finding blank tabs with addresses like lately, more often when I'm on an intermittent connection (such as the Mozilla MV office wifi).

I suspect there are a few bugs here:

* Firefox should only try prepending 'www' if the address was typed, not if it was a link click.
* Firefox should only try prepending 'www' if it gets a definitive failure, not if the DNS or HTTP request merely times out.
* Firefox should abandon the prepended 'www' URL if it gets a 404 response, and revert to showing the original error


2 years ago
Duplicate of this bug: 587950


2 years ago
Duplicate of this bug: 1184894


2 years ago
Duplicate of this bug: 1208896

Comment 47

a year ago
Confirmed on FF v45.0.1

If you try to use address bar to search on google (or other engine) strings like 'something.otherthing' it will try to go to the site something.otherthing (web page) instaed of search it on google.

Please firefox 10 years with this bug...on Chrome it doesnt happend. Thanks!
You need to log in before you can comment on or make changes to this bug.