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 21:20:18 GMT
Joe Orton wrote:
> Thank you very much Colm for decoding Bill for me.  

Ack, agreed.

> This is for FTP EPRT/EPSV support I'd guess.  I can imagine how it gets 
> broken by the ::ffff:-stripping in apr_sockaddr_ip_getbuf since you have 
> to send the serialized (family, address) on the wire for one of those 
> newfangled FTP commands.

And consider the case of plenty of UDP based operations.  Most of them
require something similar.

> So yes Bill, you'd need to add a variant of apr_sockaddr_ip_getbuf to 
> make this work and I also agree the ::ffff:-stripping should never 
> really have been done there in the first place (but now must retained 
> for compatibility, I suppose).

Thanks for that acknowledgment, so we all agree APR is broken in this

> Either way, trying to work around that with an APR resolver hack seems 
> completely wrong, -1, it will propagate v4-mapped IPv6 addresses when 
> none are necessary, that may very well break/confuse other callers.

Howso?  The user explicitly passes an IPv4 address and requests an IPv6
flavor sa.  The documentation of AI_V4MAPPED is very clear, this IPv4
acceptance will only occur if the IPv6 resolver can't first handle the
address (which is good behavior IMHO).

It's truly not a "hack" in that the getaddrinfo authors predicted it's
need, that we have treated apr's IPv4 mapped IPv6 addresses in IPv4 format,
so this "hack" simply brings full circle the host of "hacks" that you
acknowledged above were bogus.

If APR drops it's lookup behavior, I agree this new "hack" is not valid.
But that's a topic for APR 2.0, no?  In the meantime, how to resolve this
twisted creation for the authors of both TCP and most especially UDP
protocol applications?


View raw message