"Daniel Stenberg" <daniel_at_haxx.se> wrote in message
news:alpine.DEB.1.10.0902120910040.7896_at_yvahk2.pbagnpgbe.fr...
> On Wed, 11 Feb 2009, Markus Moeller wrote:
>
>> + rc = getnameinfo((struct sockaddr *)conn->ip_addr->ai_addr,
>> + conn->ip_addr->ai_addrlen, rname,
>> + sizeof(rname), NULL,
>> + 0, NI_NAMEREQD);
>> + if (rc) {
>> + failf(data, "getnameinfo() returned %d", rc);
>> + return CURLE_COULDNT_CONNECT;
>> + }
>> + if (strcmp(rname,proxy ? conn->proxy.name : conn->host.name))
>> + infof(data, "Server's real hostname is %s not %s\n",
>> + rname,proxy ? conn->proxy.name : conn->host.name);
>
> I'm a bit curious about this logic. It does a reverse lookup from the IP
> address to get a name, but why is this necessary? It would be great with a
> little comment in there explaining the reasoning. How did it end up
> getting this IP "wrongly" in the first place?
>
> Possibly more important. getnameinfo() is only present in some systems and
> you cannot assume you can use it (outside an #ifdef ENABLE_IPV6
> condition)! There are not only systems on which you need to use
> gethostbyaddr[_r]() on, but we're also optionally using c-ares for
> resolves. The fact that we don't previously do _any_ "generic"[*] reverse
> lookups within libcurl adds some trouble (== work) here since this needs a
> generic Curl_getnameinfo() or similar, that is written to work under all
> the different resolving scenarios...

Would be a copy of the fetchmail getnameinfo be OK. I think it is used
widely and came from the KAME/WIDE project. ?

>
> [*] = we do a reverse lookup in the FTP code but that is within
> ENABLE_IPV6. But from how I read the FTP code we should probably be able
> to completely remove that as I see no real need for it. It is also a bit
> ugly that it doesn't use c-ares if built with it.
>
> --
>
> / daniel.haxx.se
>
Markus
Received on 2009-02-15