Closed Bug 86449 Opened 23 years ago Closed 22 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: 23 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: 23 years ago → 22 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.