diff options
author | mark@chromium.org <mark@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-09-11 23:53:14 +0000 |
---|---|---|
committer | mark@chromium.org <mark@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-09-11 23:53:14 +0000 |
commit | 0303c1151c1baad55157bde512fc622bc863cb1b (patch) | |
tree | b6947ebb352738c2674683c73009c9cb93bdb9ca /net/base | |
parent | 099e3eb41df072bbc3dd5dd0b007595cb2a0c634 (diff) | |
download | chromium_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.cc | 17 |
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 |