Closed Bug 86449 Opened 24 years ago Closed 23 years ago

Cannot browse http://localhost when ipv6 enabled

Categories

(Core :: Networking: HTTP, defect, P4)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.0.1

People

(Reporter: erik, Assigned: neeti)

References

Details

When I enter `http://localhost' on the locationbar (to test my locally installed webserver) I am taken to Netscape Search. I have found no other way than to enter my FQDN to browse localhost -- which is annoying. I haven't been able to cross-check this on other platforms than Linux.
wfm linux 2001061808 win2k 2001061804
i'm confirming even though it's really not possible to confirm this. if localhost resolves but has no web server running on :80 we should return an error that halts the lookup process instead of falling back to the search algs. This bug was actually reported a while ago and eventually the reporter backed off when he realized that the webserver was down, but we should fix this.
Assignee: matt → neeti
Status: UNCONFIRMED → NEW
Component: Search → Networking: HTTP
Ever confirmed: true
QA Contact: claudius → benc
On my machine a webserver IS running, for sure.
There have been similar reports in bug 85020, bug 82566, and probably others. All I can say is that it all works for me on my Linux.
Reporter (Erik): Maybe this is a stupid question bit do you have something like localhost 127.0.0.1 in your /etc/hosts file? Another (actually similar) question: Does http://127.0.0.1 work?
Actually, the line in /etc/hosts should be 127.0.0.1 localhost You can get goofiness if /etc/hosts is not world-readable. The same thing applines to /etc/nsswitch.conf, /etc/resolv.conf, and /etc/host.conf if you have it. Also there should a "hosts:" line in /etc/nsswitch.conf. What does it say?
Maybe obvious as well, but type in 'ifconfig' and make sure loopback is up and running.
As I commented in the localhost bugs references by tenthumbs, you can try a couple things, depending on how silly you feel about isolating this: 1- Try localhost w/ a period. Not likely to work in URL's because of how they treat FQDN's as implicitly terminated. 2- Try moving your webserver off the loopback address (127.0.0.1) and actually onto the local interface. The actual handling of localhost is becoming a design issue, so I'm slowly trying to document this: http://www.packetgram.com/pktg/mozilla/localhost.html
Priority: -- → P4
Target Milestone: --- → mozilla1.0
/etc/hosts is world-readable and has a correct 'localhost' line. Localhost is also in my locally running DNS: dexter:~$ nslookup localhost Server: dexter.hensema.xs4all.nl Address: 192.168.1.1 Name: localhost.hensema.xs4all.nl Address: 127.0.0.1 While strange, it should be correct, as far as I know. Anyway, DNS shouldn't be used as my 'hosts:' line in /etc/nsswitch.conf reads: hosts: files dns Browsing http://127.0.0.1 does work. Browsing http://localhost. also works.
It seems you have something wrong with your loopback, after all. You should get 127.0.0.1 asking to resolve localhost. This is how RedHat 6.2 kernel 2.2.19 responds: $ nslookup localhost Server: localhost Address: 127.0.0.1 *** localhost can't find localhost: Non-existent host/domain It's fine even with the funny error message. and RedHat 7.0 kernel 2.4.0: $ nslookup localhost Server: localhost Address: 127.0.0.1 Name: localhost Address: 127.0.0.1 Both boxes return 127.0.0.1 as the IP for localhost which is the correct behaviour. Your system returns your eth0 IP number, not the lo (loopback) number It looks to me more and more like an INVALID bug. Try using another network client (like ftp, telnet, ssh) with localhost and localhost. - for example "telnet localhost" and "telnet localhost.". If the former works and the latter does not, it is certainly a problem with your Linux, not Mozilla.
The problem doesn't seem to be limited to localhost. Copy/pasting the url from my mail led me to: http://search.netscape.com/google.tmpl?search=http%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D86449 Anyway: both `telnet localhost' and `telnet localhost.' works: they both don't use a DNS lookup, but use /etc/hosts directly. Note: I took the entry of localhost in my DNS server from the Linux DNS-HOWTO and I've been running this config for years now, without any problems.
I have no doubt that mozilla is doing something silly. There are just too many reports like this on otherwise working systems. The trick is to figure out what's happening. Nslookup, dig, and host are not good tools for investigating this issue because they come from the BIND package and *only* use DNS. That's not the problem here.
Tenthmbs: you are wrong about nslookup not using /etc/hosts. See the examples I posted above. On the same computers, "host localhost" gives me "Host not found". See the difference?
OK. I retract my last comment. Tenthumbs is right, at least in part (see below). I just haven't used nslokup for years (I prefer host). The first two lines of nslookup output is the server it used for the lookup. That still leaves the RH7.0 box which has nslookup responding with 127.0.0.1 and host with "Host not found". I believe nslookup must have used /etc/hosts here. It seems there are really different implementations of nslookup and/or the loopback.
nslookup is a DNS only tool (unless some UNIX OEM distributor got fancy on me). That's sort of the sucky thing, the problem we are looking here is "name" resolution, and DNS is only one component of name resolution. This is likely a name resolution problem in Mozilla. The fact that for the proxy bug "localhost" broke but "localhost." (an FQDN with explicit termination) suggests that there is something going on. RE: /etc/nsswitch.conf, files = /etc/hosts. You are looking at /etc/hosts, then going to DNS (by reading /etc/resolv.conf). You can test this by doing silly things like creating entries for msn to cnn (just kidding). RE: nslookup failing in different Linux versions, there is probably something different with the configuration of the systems (or my first comment about nslookup is true...)
What about 'ping localhost' and, on linux at least, 'resolveip localhost'. Those are the two I use normally to check.
The simplest test would be to compare lynx http://localhost/ and mozilla http://localhost/ from the same xterm. (You would have to set some environment variables if you want lynx to use a proxy). If lynx succeeds and mozilla does not then mozilla is clearly broken. I have a simple test program for gethostbyname. It's available if anyone wants to try it.
I have fixed my DNS server, on a 'nslookup localhost' it now returns 'localhost' instead of 'localhost.hensema.xs4all.nl'. Pinging localhost, browsing with lynx, w3m, netscape navigator, konquerer: no problem. I simply haven't got any problem with my setup (and it has worked for years) and Mozilla is the only application that has a problem connecting to localhost.
Build 2001062721 I have this problem as well, including the following symptoms: I am connected to the net via dialup ppp only, and I am not running a local DNS server. When my remote DNS server returns 127.0.0.1 in response to an `nslookup localhost', I can access my local httpd. When it cannot resolve localhost, I ma directed to www.localhost.com. The DNS server of my current ISP does not recognize localhost. Using localhost.localdomain gets me no further; neither does 127.0.0.1. The lo interface is up. `telnet locahost' works. Navigator 4.75 works. This is a painful bug if one is trying to configure apache or tomcat in an environment like mine.
If you can't connect w/ 127.0.0.1 you probably are using a proxy and haven't excluded it from proxy redirection.
The proxy setting was the problem.
no problem. definite relnote material. *** This bug has been marked as a duplicate of 31510 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
In what is this a duplicate of bug 31510? 31510 is about proxying, and this problem is completely unrelated to a proxy. Note that Peter B. West reported a problem which was unrelated to this one on second sight.
Erick: is the definition of the problem now: http://localhost. works http://localhost doesn't? If so, reopen the bug.
Yes. Both 'localhost' and 'http://localhost' take me to the netscape search page, 'localhost.' doesn't.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
severity: major Neeti: This problem needs traction, we are getting lots of complaints from Linux users for URL and proxy settings that use "localhost" as a string. If you are not going to work on this, can you triage it to the correct person's queue?
Severity: trivial → major
The only real difference between 4.x and mozilla at the resolver level is tha t4.x uses gerthostbyname and mozilla uses gethostbyname2. Reporter, do you have IPV6 support enabled in your kernel?
Is there any pre-processing of the hostname before it is sent to localhost? All these localhost bugs have the same common demonimator, "localhost" is not sent to name resolution in the OS correctly.
I have IPv6 enabled in my kernel, here are some relevant bits of information: eth0 Link encap:Ethernet HWaddr 00:00:C5:5D:E1:18 inet addr:212.120.97.185 Bcast:212.120.97.255 Mask:255.255.254.0 inet6 addr: fe80::200:c5ff:fe5d:e118/10 Scope:Link eth1 Link encap:Ethernet HWaddr 00:40:33:2F:C9:52 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::240:33ff:fe2f:c952/10 Scope:Link (eth0 is connected to my cablemodem, IPv6 addresses automatically configured by the kernel) /etc/hosts: 127.0.0.1 localhost # special IPv6 addresses ::1 localhost ipv6-localhost ipv6-loopback IPv4 routing table: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth1 212.120.96.0 * 255.255.254.0 U 0 0 0 eth0 default r1-fe1-0.hnglo1 0.0.0.0 UG 0 0 0 eth0 Adding localhost to the routing table doesn't help and should not be needed.
Aha! Do you have a line like ::1 localhost in /etc/hosts? If not, try adding it.
Well, I see you do. Sorry about that. What do you have for /etc/host.conf and /etc/resolv.conf? What does "dnsdomainname" say?
I guess I'm not well organized today so soory for the spam, but try this. Add one of these lines 127.0.0.1 me.example me ::1 me.example me to /etc/hosts and see if mozilla likes http://me/ or http://me.example/ I would try one at a time and then both together.
Results with `me.example' in /etc/hosts: When trying to browse http://me, I get redirected to search.netscape.com. When browsing http://me.example, I get a `connection refused' (!!). Both the IPv4 and the IPv6 variant exhibit the same behaviour. Cross checking with Netscape Navigator: both me and me.example work, but offcourse only for the IPv4 address. /etc/host.conf: order hosts, bind multi on dexter:~$ cat /etc/resolv.conf search hensema.xs4all.nl hnglo1.ov.nl.home.com nameserver 192.168.1.1 dexter:~$ rpm -qf /usr/sbin/named bind9-9.1.0-2 dexter:~$ dnsdomainname hensema.xs4all.nl
That's _very_ interesting but I'm not sure what it means, other than the fact that something is wrong. I noticed that the loopback interface is missing from your routing data. Did you just omit it or is it really not configured? Are you willing to compile and run a test program? I have one that exercises gethostbyname2.
I really don't have a route to localhost. I haven't configured this intentionally: it seems to be the standard configuration for Suse 7.1 and/or Linux 2.4. Offcource I am willing to run a test program. Attach it to this bug (or post a URL or mail me) and I'll give it a whirl. I'm a C-programmer so don't try to make it too mokey-proof ;-)
netdbTrace output: (first, lets go to bugzilla:) netdbTrace: gethostbyname2(bugzilla.mozilla.org, AF_INET6) netdbTrace: (null) netdbTrace: gethostbyname2(bugzilla.mozilla.org, AF_INET) netdbTrace: official name: mothra.mozilla.org netdbTrace: alias[0]: bugzilla.mozilla.org netdbTrace: address[0]: 207.200.81.216 (now, visit localhost:) netdbTrace: gethostbyname2(localhost, AF_INET6) netdbTrace: official name: localhost netdbTrace: alias[0]: ipv6-localhost netdbTrace: alias[1]: ipv6-loopback netdbTrace: address[0]: 0.0.0.0 netdbTrace: gethostbyname2(localhost, AF_INET) netdbTrace: official name: localhost netdbTrace: address[0]: 127.0.0.1 (but mozilla decides otherwise:) netdbTrace: gethostbyname2(keyword.netscape.com, AF_INET6) netdbTrace: (null)
*** Bug 85312 has been marked as a duplicate of this bug. ***
Sorry about the delay in responding here. I should point out that I sent the reporter a small test library to capture gethostbyname* calls. Assuming the results are all from mozilla, the thing that jumps out is that IPv6 thinks that localhost is on 0.0.0.0 which is the default route and doesn't appear to be the local machine (at least according to the routing table). I have no idea why IPv6 and IPv4 lookups are different but that's probable where things are going wrong.
I'm seeing the localhost problem too on a SuSE 7.1 with 2.4 kernel.
It seems to me the resolving process itself is working fine for localhost, at least it gives no error, but *what* is being resolved seems to be the problem. Looks like one has to dig into nsSocketTransport.cpp and figure out the content of the netaddr struct.
Andreas: do you have an IPv6-aware kernel? In the other case here, gethostbyname2 returned different results for IPv4 and IPv6.
Yes, I seem to have the same configuration as Erik. And it certainly looks like gethostbyname2 does not like it and returns 0.0.0.0 as localhost. Really strange thing, this is maybe NSPR stuff or a glibc problem.
I'm beginning to think that mozilla should have IPv6 disabled by default and require explicit user action to enable it. IPv4 has been around for decades and there are still buggy implementations out there. IPv6 is so new that it is bound to fail more often than it works.
I fell into the trap I accused otheres of doing. An IPv6 network address is 16 bytes long. The first four bytes of ::1 are always 0 which is what we're seeing. I built a Linux 2.2.19 kernel with IPv6 support as a module. If I load the module and add the appropriate entry into /etc/hosts then gethostbyname2 returns correct data. from a simple test program I wrote: Testing gethostbyname2(localhost, AF_INET6) official name: localhost alias[0]: localhost6 address[0]: 0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:1 Testing gethostbyname2(localhost, AF_INET) official name: localhost address[0]: 127.0.0.1 I also now see mozilla die. Running ethereal on the loopback interface shows just a pair of SYN and RST packets. The big problem is that you can't unload the IPv6 kernel module so you have to reboot to reset things. Wherever the bug is, IPv6 just doesn't seem worth it.
Is everyone who has this problem using IPv6? If so, I'll update the summary. Created bug 96432.
As a convenience and security measure, i have 127.0.0.1 ad.doubleclick.net in my /etc/hosts file. In Netscape, any image which is served by ad.doubleclick.net is rendered as a broken link. In Mozilla, I get a "Connection refused by server" error dialogue, and i have to click "ok" to clear the dialogue. i think that my issue may be related to this bug, i'm no networking or programming expert. but i can report that it is quite a beating when i have to click the "ok" dialogue button four times for each pageview on http://www.cdnow.com :-| thanks
Lee, I think that is the way it is supposed to work, because unless you are running apache or something on your local box, mozilla cannot connect to it. You could try taking the line out of /etc/hosts, then if you right-click on an image from doubleclick you should be able to block it from loading images using the context menu.
except block images from server is not available anymore in the browser context menus.. between 0.9.5 and 0.9.6 it was taken out. Why? Good question..
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
the problem with localhost seems to be the following: on IPv6 enabled/configured hosts mozilla can resolv localhost to its IPv6 adress and tries to connect. But Apache and others (like IMAP, NNTP) are mostly not IPv6 capable. So the connect will be refused. It has to be done like in telnet clients which try to connect to the IPv6 address and if this fails try to connect to the IPv4 address. Can somebody give a hint where to find the resolver code in mozilla? Then I can take a look into it.
*** Bug 104703 has been marked as a duplicate of this bug. ***
On SuSE Linux 7.2, where Netscape Version 4.77 [de]-20010326 and 'telnet localhost 80' did not seem to have any problem, but Mozilla {Build Id: 2001101202} would report that access to localhost was denied (which also breaks access from Mozilla to this distribution's http-based on-line help system and printer control), I have identified the following possibility for a workaround resolving this issue: Comment out this line in /etc/hosts as follows: #::1 localhost ipv6-localhost ipv6-loopback (Note/Caveat/Disclaimer;-/: This might break other, IPv6-dependent stuff, if any such thing should be in use on the machine, and requiring the above loopback...) You will have to quit and restart Mozilla in order for the change to take effect (for reasons probably associated to bugs 117613 and 64857).
I confirmed this bug on SuSE 7.3, apache running and tested, mozilla 2002020511 kernel 2.4.18 - with ipv6 enabled (but mostly unused yet) ipv6 123552 -1 (autoclean) my tcpdump (syn->rst) votes for Wolfgang Rosenauers explaination 19:14:02.314572 ::1.32801 > ::1.80: S 168236272:168236272(0) win 32752 <mss 16376,sackOK,timestamp 142417 0,nop,wscale 0> 19:14:02.314612 ::1.80 > ::1.32801: R 0:0(0) ack 168236273 win 0 thus resulting in that message: the connection was refused when attempting to contact localhost Luckily Andreas Grosches workaround really helps. I suppose this problem is not limited to HTTP. Unluckily I can not test this (because my in.ftpd responded both to IPv4 and IPv6 properly)
This works for me running Mozilla 2002031008 (aka mozilla 0.9.9) on SuSE 7.3 kernel 2.4.18. Earlier builds (e.g.: mozilla 0.9.8) did show this bug with the same configuration. Could this be fixed with the checkins for Bug 86917 ?
Reporter, could you please try this problem again on a recent build?
modifying summary per comments
Summary: Cannot browse http://localhost → Cannot browse http://localhost when ipv6 enabled
I'm not the reporter but it works for me since some releases. I think this bug can be closed?
wfm per comments above
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.