(No comment was entered for this change.)

eroman: this bug is a duplicate or variant of  issue 32522 .

(No comment was entered for this change.)

Based on discussion with WTC, the problem is that when there are not network 
interfaces up, that GetAddrInfo (with the parms we currently pass it) returns host 
not found.  Without the command line argument, or probing similarly determines that 
no IPv6 connections is possible, and then explicitly restricts GetAddrInfo to IPv4 
(making it impossible to reach your localhost variant).

This is apparently a more general problem, and appears in other bugs such as 41408.

We could special case the (many) localhost flavors... or.... we could time how long 
it takes to say "host not found."  If it is really fast, then we would wouldn't delay 
the user much if we tried again, so we should call GetAddrInfo again with  out using 
AddrConfig to restrict the results. This should handle everything with relatively 
little special code.  If a host-not-found takes 10-12 seconds, then it it is probably 
a real lookup, and we should not bother to repeat the process.

Just to correct, this problem does not just appear when there are no interfaces up, 
it appears when there are no External interfaces up, the lo: interface is up 
everytime I have encountered the problems, there just isn't a DNS resolver reachable, 
and no external interfaces (eth0, Wlan0, etc), however lo: is up, so there is an 
interface up.

You really shouldn't do a DNS lookup on an IP address like 127.0.0.1, however google 
chrome, and now firefox has started doing it too fails to connect to the service 
running on 127.0.0.1.   They seem to assume that the whole system is offline and 
nothing can be reached if there is no resolver, and ignores the fact that there may 
be local services running.

It just seems odd to me that the failure of not resolvable appears on an IP Address, 
as that really should not ever be resolved, as that would render the browser 
unworkable if it ever was run on a server where you had replaced the external router 
- no current DNS reachable.

Host lookup on localhost fails on the dns resolver (host, nslookup etc), however, 
chrome and firefox etc can resolve localhost when online, but not when offline.

programs like ssh, telnet, and many others, can resolve localhost, and 127.0.0.1 when 
the system is offline, without any problems or delays.  Perhaps that's a place to 
compare.

If you see the attached image, you can see that a 127.0.0.1 connection fails with a 
resolver error.

	chrome-bug.jpg 53.9 KB   View   Download

(No comment was entered for this change.)

I'm seeing this problema, and actually getaddrinfo works while offline here, when 
tested from python, be it with AI_ADDRCONFIG, AI_CANONNAME or both or none.

But chrom(e|ium) fails to connect to localhost or 127.0.0.1 or ::1, while firefox 
works with those three "hosts". This forces me to open firefox to prepare my classes 
or test my http code while commuting offline... :(

An information update, I used mobile broadband, and usually run into the problem while working on software on the trains, running between hills.

When the signal on the broadband gives out, then chrome cannot connect to localhost nor 127.0.0.1.  (the broad band connection is gone, the /etc/resolv.conf is empty, and ONLY the lo device is present), then chrome hangs on resolve.

However, restarting chrome, and suddenly it can resolve localhost, and 127.0.0.1, and does so very quickly, though there is no network present.

I ran a few tests, I've even tried dummying an internet connection, and pointing the dns to a 127.0.0.1, but nothing would allow chrome to see localhost.

But restarting chrome with no connection, and it suddenly behaves as I expected.

until I get a connection, and it drops.

On Ubuntu offline chrome 5.0.375 cannot open localhost even when run from command line:
google-chrome --enable-ipv6 --enable-plugins

Did not work.

Not sure what "ubuntu offline" is referring to in the previous comment.

But I can confirm that on ubuntu 9.10 and using chrome 5.0.375.70 using the --enable-ipv6 switch does fix the problem for me.

I used ifconfig to ensure only lo interface was up.

The earlier version of beta version (of chromium not chrome) I was using did not suffer from this problem  but I'm afraid I didn't keep a record of which build number  that was.

[This suggestion really came from comments/discussion with Wtc]: Perhaps when we "test for viability" of IPv6, there is truly no support for it.... but then... perhaps IPv6 changes state enough to support it (example: a previously down IPv6 interface is brought up).  In general, we watch for major network changes, and then revalidate IPv6 viability.  Unfortunately, we don't monitor changes that are IPv6 specific, as those events appear with tremendous frequency, appeared to be mostly irrelevant, and could plausibly impact performance.  It could be that we need to better filter the IPv6 events so that we can watch for viability-changing events, and not be distracted small address change notifications and such.

Firefox works fine, Chrome doesn't when disconnected from Internet

Chromium 6.0.453.0 Ubuntu 10.04

~$ chromium-browser --enable-ipv6 --enable-plugins

Not working for me, never has....Makes doing web development a bit of a challenge!!

	Screenshot.png 252 KB   View   Download

Cleaning up mstone:6 bugs, default assumption is that bugs w/ no os are os-all

(No comment was entered for this change.)

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=58534 

------------------------------------------------------------------------
r58534 | vandebo@chromium.org | 2010-09-03 13:34:27 -0700 (Fri, 03 Sep 2010) | 10 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/address_family.h?r1=58534&r2=58533
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.cc?r1=58534&r2=58533
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_proc.cc?r1=58534&r2=58533
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/mock_host_resolver.cc?r1=58534&r2=58533

Fix remaining localhost resolution issues.

If host resolution is restricted to a single address family and the results of a resolution are all localhost of that type, try again without the address family restriction.

Also make --disable-ipv6 apply to resolution of ip literals.

BUG=42058, 49024, 32522
TEST=Manual testing in various network configurations. See https://spreadsheets.google.com/ccc?key=0AhSnKEusL6UgdFZIRmxTUnYtZDhjX3lKclBqMHo4YUE&hl=en&authkey=CLKDxMYB

Review URL: http://codereview.chromium.org/3231005
------------------------------------------------------------------------

I made several changes to address this and all related bugs.  If you continue to experience problems related to this bug after r58535, please create a new bug and reference it here.  There is much conflicting information in this bug report, so a fresh start for any further issues would be helpful.

When is this scheduled to go in production / released in a stable build?  

It made the M7 cut.  M6 hit stable on Sep 2, so about six weeks after that unless M7 is not deemed releasable, in which case, 12 weeks.

Thanks for the prompt response!!! If I need it before that, is this available as a patch or do I have to build with latest code? I need a ubuntu debian build.

thanks much!

M

It's been in the tree long enough, that it's in the Dev channel: http://www.chromium.org/getting-involved/dev-channel

Thanks! Just tried it out. Installed version: 7.0.517.0 dev

With this I can get to "http://127.0.0.1 but still cannot get to "http://localhost when not connected to Internet. Firefox works when I un-check the "Work offline" checkbox under "File" menu.

I checked my /etc/hosts looks ok, when I ping localhost I get response from 127.0.0.1

Do I need to update anything in chrome config for this?

Thanks,

M

Please file a new bug and post the bug number here - There is a lot of conflicting information in this bug and I made several changes to address the problems, so a fresh slate of information will make things clearer.

In your bug report, please include:
1) The output of "host localhost"
2) The output of "dig -tany +noall +answer localhost"
3) The output of "netstat -ln | grep :80"
4) The output of "google-chrome --version"
5) Goto chrome://net-internals/#dns , click the "Clear host cache" button, try to load http://localhost then include the content of chrome://net-internals/#dns

If you are familiar with these commands, some of them may seem redundant, but each one does provide different information in this case.

Created a new issue:

http://code.google.com/p/chromium/issues/detail?id=55041