apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r602176 - /apr/apr/trunk/network_io/unix/sockaddr.c
Date Mon, 10 Dec 2007 18:57:18 GMT
Joe Orton wrote:
> I am getting pretty sick of trying to decode the meaning behind oblique 
> remarks in commit messages.  Is that supposed to help explain the 
> motivation for this change?  Who is "we"?  What addresses have been 
> coerced by whom?  What is a "socket lookup call"?

Great; dialog, thank you :)  Precisely why this isn't backported.
Let me clarify, please?

For example, httpd takes a connection on IPv6 over ::ffff:
(an IPv4 mapped address, the socket and sockaddr structures created
by APR) and records the result of apr_sockaddr_ip_get;

         /* This is an IPv4-mapped IPv6 address; drop the leading
          * part of the address string so we're left with the familiar
          * IPv4 format.
         memmove(buf, buf + strlen("::ffff:"),
                 strlen(buf + strlen("::ffff:"))+1);

which causes "" or any other mapped address to be recorded.

HOWEVER, we do not modify the ->family elements to state APR_INET.
That's fine, but ->family and this IP are internally inconsistant.

Now apr has provided a tuple of ip address, family and port that
cannot be reconstituted by APR.  So, for example, where we have
to create a connection to the very same host/family on a different
port, it becomes impossible.

>> Unfortunately, we failed to resolve, for example,
>> for INET6 addressing, where we would resolve ::ffff:
> If apr_sockaddr_info_get is called with family==AF_INET6 and the given 
> hostname does not map to any IPv6 addresses, I would expect failure.  
> Why is the caller not using family==AF_UNSPEC if they don't know the 
> family which the addresses of the given hostname might map to?

They know the family and IP from an existing connection, and that
existing connection is internally inconsistent.

Do we need a flavor of apr_sockaddr_ip_get that returns a usuable
address that corresponds to the apr_sockaddr_t's ->family?

Or would you have an entirely different suggestion?

View raw message