summaryrefslogtreecommitdiffstats
path: root/net/base
diff options
context:
space:
mode:
authormark@chromium.org <mark@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-09-11 23:53:14 +0000
committermark@chromium.org <mark@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-09-11 23:53:14 +0000
commit0303c1151c1baad55157bde512fc622bc863cb1b (patch)
treeb6947ebb352738c2674683c73009c9cb93bdb9ca /net/base
parent099e3eb41df072bbc3dd5dd0b007595cb2a0c634 (diff)
downloadchromium_src-0303c1151c1baad55157bde512fc622bc863cb1b.zip
chromium_src-0303c1151c1baad55157bde512fc622bc863cb1b.tar.gz
chromium_src-0303c1151c1baad55157bde512fc622bc863cb1b.tar.bz2
Non-blocking connect() attempts may fail synchronously in some cases. When
this occurs, connect() should be retried with another address if possible and appropriate. On Mac OS X 10.6 ("Snow Leopard"), getaddrinfo() returns IPv6 addresses even when inappropriate due to the use of AI_ADDRCONFIG. connect() fails immediately when trying to connect to an IPv6 address from a system that only has IPv4 connectivity. The existing net::TCPClientSocketLibevent is not prepared to deal with immediate connect() failures, so it fails without trying additional addresses. Some sites, such as python.org, publish both IPv4 and IPv6 addresses. On Snow Leopard, name resolution always returns the IPv6 addresses first, rendering such sites impossible to connect to unless reachable by IPv6. This change restores the previous behavior of setting AI_ADDRCONFIG when calling getaddrinfo() on Mac OS X. AI_ADDRCONFIG was removed in a previous attempt to fix this bug. AI_ADDRCONFIG is now documented in Snow Leopard. The associated comment, written for Mac OS X 10.5 ("Leopard"), is no longer correct. In most cases, the presence or absence of this flag seems to have no impact on the system resolver's behavior, but I believe that its presence is correct per the documentation. A separate bug will be filed with Apple. BUG=12711 TEST=http://python.org/ on Snow Leopard should load on a machine where only IPv4 is available; it (and all other sites) should continue to function properly on Leopard Review URL: http://codereview.chromium.org/196094 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26051 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'net/base')
-rw-r--r--net/base/host_resolver_proc.cc17
1 files changed, 0 insertions, 17 deletions
diff --git a/net/base/host_resolver_proc.cc b/net/base/host_resolver_proc.cc
index 6c9400d..8951646 100644
--- a/net/base/host_resolver_proc.cc
+++ b/net/base/host_resolver_proc.cc
@@ -157,23 +157,6 @@ int SystemHostResolverProc(const std::string& host, AddressList* addrlist) {
// address.
// See http://crbug.com/5234.
hints.ai_flags = 0;
-#elif defined(OS_MACOSX)
- // We don't need to use AI_ADDRCONFIG on Mac OS X. There are two evidences:
- //
- // 1. The getaddrinfo man page on Mac OS X documents only three flags:
- // AI_CANONNAME, AI_NUMERICHOST, and AI_PASSIVE, and shows an example that
- // sets hints.ai_flags to 0.
- // 2. The <netdb.h> header lists only those three flags in the comment after
- // the ai_flags field of struct addrinfo, and defines an AI_MASK macro as
- // the bitwise-OR of those three flags with the comment "valid flags for
- // addrinfo".
- //
- // But is it harmful to use AI_ADDRCONFIG? Unfortunately I can't find a
- // definitive answer by browsing the getaddrinfo source code in Darwin (in
- // the Libinfo project).
- //
- // See http://crbug.com/12711.
- hints.ai_flags = 0;
#else
hints.ai_flags = AI_ADDRCONFIG;
#endif