Open Bug 66183 Opened 24 years ago Updated 2 years ago

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

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

People

(Reporter: bugzilla, Unassigned)

References

Details

if you enter "gemal1.dk" in the Location field and press Enter you eventual get an error message saying: "www.gemal1.dk could not be found. bla bla." if you press "Ok" the location field still says: "gemal1.dk" The error message should say "gemal1.dk" NOT "www.gemal1.dk" Build 20010121
Adding to meta bug for error handling
Blocks: 61685
Mozilla automatically tries adding a "www." whenever a second-level domain name you type into the location bar doesn't resolve (such as http://cmc.edu). It also does that, erroneously (bug 34943), when you cilck a link to cmc.edu. (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: "gemal1.dk could not be found (also tried www.gemal1.dk)".
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 Location: http://intelegence.com/traction/ There is no such host, so we report that "www.intelegence.com" was not found. Since www.intelegence.com exists and can be accessed just fine, this is rather confusing.
Keywords: correctness
Target Milestone: --- → Future
*** Bug 68534 has been marked as a duplicate of this bug. ***
mass move, v2. qa to me.
QA Contact: tever → benc
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 www.whatever.com? It's a waste of bandwith, and almost all important sites work without www. anyway.
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.
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.
I believe fixing bug 115539 will also fix this. Marking dependent on 115539.
Depends on: 115539
.com is also added to dialog. type in 'sdfdsf', mozilla says 'www.sdfdsf.com' could not be found. We *REALLY* should be saying: sdfdsf, sdfdsf.com, and www.sdfdsf.com 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
docshell
Assignee: neeti → adamlock
Component: Networking → Embedding: Docshell
QA Contact: benc → adamlock
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)
dupe of bug 95390?
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 http://noSuchHost.com/ and http://www.noSuchHost.com/, and the error message that is displayed when that lookup fails. This problem happens even with "internet keywords" disabled.
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. ***
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, sdfdsf.com, and www.sdfdsf.com 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.
QA Contact: benc → adamlock
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 www.foo.com could not be found it is confusing, however considering the prefs told Mozilla to try www.foo.com 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
QA Contact: adamlock → benc
*** Bug 290749 has been marked as a duplicate of this bug. ***
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.
browser.urlbar.matchOnlyTyped I think is the pref you actually want zolba, however, at least in FF 1.5.0.1 on the mac, it doesn't seem to work.
er, duh, as http://www.mozilla.org/docs/end-user/domain-guessing.html clearly documents, it is browser.alternate.*; which does work. In any case, this isn't keywords.
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.
(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
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 myserver.company.co.jp lookup in Firefox: 8.791980 -> DNS Standard query A myserver.company.co.jp 8.808357 <- DNS Standard query response A xx.yy.xx.yy 8.814991 -> DNS Standard query A www.myserver.company.co.jp 8.831450 <- DNS Standard query response, No such name 8.832966 -> DNS Standard query A www.myserver.company.co.jp 8.849451 <- DNS Standard query response, No such name 8.851029 -> DNS Standard query A www.myserver.company.co.jp 8.859189 <- DNS Standard query response, No such name 8.861028 -> DNS Standard query A www.myserver.company.co.jp 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 myserver.company.co.jp lookup
(sorry, submitted too soon). If I retry LATER, the initial myserver.company.co.jp 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
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.
I just now found this when trying to open up: http://minimalmac.com/post/18189678921/tv-is-broken It has following hosts: minimalmac.com has address 72.32.231.8 Host www.minimalmac.com 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.
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: minimalmac.com 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 minimalmac.com 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
Another example: Search for dsadqwqdqdada.com in address bar (or other random non-existent domain) Firefox tries dsadqwqdqdada.com Firefox tries www.dsadqwqdqdada.com Firefox changes address bar to www.dsadqwqdqdada.com 1) The address entry should not be changed. Network issues may prevent access. Both dsadqwqdqdada.com and www.dsadqwqdqdada.com 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 www.dsadqwqdqdada.com 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.
I've been finding blank tabs with addresses like http://www.t.co/aQVI2kvMxu 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
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!
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.