"Daniel Stenberg" <daniel-curl_at_haxx.se> said:

> Aha, you meant a host with getaddrinfo() that can't resolve ipv6! True. That's
> a bug indeed.

Basically yet, but also an IPv6-only host that cannot resolve to an IPv4
address (rare case I know).

> Gosh. The reason for that socket(PF_INET6) check there is that some platforms
> (Linux is one) perform drasticly slower name resolves if attempting to resolve
> getaddrinfo(PF_UNSPEC) without having an ipv6-enabled stack.

Then it's more important that C-ares should support IPv6. Can't be
that hard,.. or?

> I agree. But having -6 (CURL_IPRESOLVE_V6) should enforce PF_INET6 to
> getaddrinfo() and then it should fail if no v6 address is available.
>
> Or have I missed something?

I think we agree. Will test as soon I've reinstalled the IPv6 stack.
 
BTW. The hostip.c code "socket(PF_INET6,)" will always fail on Win-XP
if no IPv6 stack present. IMHO it's better to have socket() fail in url.c instead
(so we know the resolve part is okay). This function seems to work:

static bool can_resolve_ip6 (void)
{
#ifdef WIN32
  struct in6_addr ip6 = {{ IN6ADDR_LOOPBACK_INIT }}; /* ::1 */

  /* This should never block */
  if (gethostbyaddr((const char*)&ip6,sizeof(ip6),AF_INET6))
     return (TRUE);
#else
  curl_socket_t sock = socket(PF_INET6, SOCK_DGRAM, 0);
  if (sock != CURL_SOCKET_BAD) {
    sclose(s);
    return (TRUE);
  }
#endif
  return (FALSE);
}

Then fallback to "pf = PF_INET" if can_resolve_ip6() == FALSE.

Don't know why all targets couldn't use such heuristics.

And also, there seems to be no way in Win-2k/XP w/o a IPv6 stack to
print an IPv6 address (allthough getaddrinfo() returns AF_INET6 just fine).
It would be handy to add a inet_ntop() (and inet_pton()) function for this case.
I have one adapted from Paul Vixies implementation.

--gv
Received on 2004-04-14