On 6/7/07, Joe Orton <[EMAIL PROTECTED]> wrote:
On Wed, Jun 06, 2007 at 08:15:49PM -0300, Davi Arnaut wrote:
> Same machine, now with -n:

Thanks.  Was the last line omitted from the results for Solaris which
you posted, or was it really a NULL result list?

I don't think this provides any reason to change the APR resolver code.
Ubuntu systems may be a bit schizophrenic about whether ::1 exists,
depending on whether your app uses AI_ADDRCONFIG or not, but it seems to
be by design.


The code that sets AI_ADDRCONFIG checks the error message returned by
getaddrinfo. If family was APR_UNSPEC and the error was EAI_BADFLAGS
(which basically means failed because of a bad flag:) ) it retries
with flags set to null.

I think the Ubuntu 7.04 people wrongfully return EAI_ADDRFAMILY, when
EAI_BADFLAGS would be just fine, because changing the flag makes the
call succeed and there is a ::1 address in the specified family.

A solution that *works* is to check for both error codes and if either
is returned and were in APR_UNSPEC mode, retry without EAI_ADDRFAMILY.

The testsockets.c problem is certainly not new, I don't see why it
should block a release.  That code has always been pretty fragile.

joe


--
Lucian Adrian Grijincu

Reply via email to