Daniel Johnson reported and fixed ipv4 name resolves when libcurl is built

with ipv6-enabled c-ares

diff --git a/CHANGES b/CHANGES
index ad335f725bffcd7e0f26d18c685b5a6dc64c045e..5b6c8976c1184b6688368f6396c647421e1abbbd 100644 (file)
--- a/CHANGES
+++ b/CHANGES
@@ -6,6 +6,26 @@
 
                                   Changelog
 
+Daniel Stenberg (2 Nov 2008)
+- Daniel Johnson reported and fixed:
+
+  When c-ares isn't enabled, libcurl by default calls getaddrinfo with family
+  set to PF_UNSPEC which causes getaddrinfo to return all available addresses,
+  both IPv4 and IPv6. Libcurl then tries each one until it can connect. If the
+  net connection doesn't support IPv6, libcurl can still fall back to IPv4.
+
+  However, since c-ares doesn't support PF_UNSPEC, when it's used it defaults
+  to using family=PF_INET6 and therefore only returns IPv6 addresses when AAAA
+  records are available, even if IPv4 addresses are also available. The effect
+  is that since my ISP doesn't do IPv6, libcurl can't connect at all to a site
+  that has AAAA records. It will work if I explicitly use CURL_IPRESOLVE_V4 or
+  --ipv4 with the curl tool. I discovered this when curl would fail to connect
+  to seemingly random sites. It turns out they weren't random, they were sites
+  with AAAA records.
+
+  So now libcurl defaults to PF_INET... until c-ares has been tought to offer
+  both.
+
 Daniel Fandrich (29 Oct 2008)
 - Fixed a bug that caused a few bytes of garbage to be sent after a
   curl_easy_pause() during a chunky upload. Reported by Steve Roskowski.

diff --git a/RELEASE-NOTES b/RELEASE-NOTES
index 3e418f20dc29f69a5c21c1a643a2fd9f813f1ec0..86c4683be7892660f3d96095f8abccffdd88900c 100644 (file)
--- a/RELEASE-NOTES
+++ b/RELEASE-NOTES
@@ -41,6 +41,7 @@ This release includes the following bugfixes:
  o case insensitive string matching works in Turkish too
  o Solaris builds get _REENTRANT defined properly and work again
  o Garbage sent on chunky upload after curl_easy_pause()
+ o ipv4 name resolves when libcurl is built with ipv6-enabled c-ares
 
 This release includes the following known bugs:
 
@@ -57,6 +58,8 @@ advice from friends like these:
  Linus Nielsen Feltzing, Martin Drasar, Stefan Krause, Dmitry Kurochkin,
  Mike Revi, Andres Garcia, Michael Goffioul, Markus Moeller, Rob Crittenden,
  Jamie Lokier, Emanuele Bovisio, Maxim Ivanov, Ian Lynagh, Daniel Egger,
- Igor Novoseltsev, John Wilkinson, Pascal Terjan, Steve Roskowski
+ Igor Novoseltsev, John Wilkinson, Pascal Terjan, Steve Roskowski,
+ Daniel Johnson
+ 
 
         Thanks! (and sorry if I forgot to mention someone)

diff --git a/lib/hostares.c b/lib/hostares.c
index d7dceaa1da31af9d791dd7d784adfe255f95f393..f17cdf5ecff811fd9fee8221cf8cdbad62208446 100644 (file)
--- a/lib/hostares.c
+++ b/lib/hostares.c
@@ -399,9 +399,12 @@ Curl_addrinfo *Curl_getaddrinfo(struct connectdata *conn,
 
   switch(data->set.ip_version) {
   case CURL_IPRESOLVE_V4:
+  default: /* By default we try ipv4, as PF_UNSPEC isn't supported by c-ares.
+              This is a bit disturbing since users may very well assume that
+              both kinds of addresses are asked for, but the problem is really
+              in c-ares' end here. */
     family = PF_INET;
     break;
-  default: /* by default we try ipv6, as PF_UNSPEC isn't supported by (c-)ares */
   case CURL_IPRESOLVE_V6:
     family = PF_INET6;
     break;