You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2003/09/09 15:56:59 UTC

resolver confusion (was "Re: Tagged the trees")

Jeff Trawick wrote:
> Sander Striker wrote:
> 
>> I tagged the trees today, as STRIKER_2_0_48_PRE1 and STRIKER_2_1_0_PRE1
>> respectively.  I'll try and get some tarballs up for testing, but
>> for now, please test the tag.
> 
> 
> with recent apr resolver changes, Apache on AIX has picked up the old 
> assert failure that solaris-8-with-no-patches used to have... 
> investigating further...

(I think this is a different assert() failure.  I don't think the call 
presently failing used to go to the resolver, and now it does.)

It looks like AIX's getaddrinfo() always fails if service is "0", which 
should be easy to work around in APR (and a good excuse to bother the 
AIX resolver folks as the same call seems to work on some other 
platforms, but meanwhile I have questions about the call in Apache that 
fails.  Specifically, it is possible that Apache should change because 
of a semantics change in apr_sockaddr_info_get()?

The code that pukes in server/config.c is

      /* NOT virtual host; don't match any real network interface */
      rv = apr_sockaddr_info_get(&s->addrs->host_addr,
                                 NULL, APR_INET, 0, 0, p);
      ap_assert(rv == APR_SUCCESS); /* otherwise: bug or no storage */

In prior APR, a call with hostname=NULL meant "just build me a sockaddr" 
but now it means we call getaddrinfo() with AI_PASSIVE flag set.

Conceptually, specifying AI_PASSIVE results in a list of socket addrs 
that the app should bind to.  "Just build me an IPv4 sockaddr" is 
different than that.  But I don't know where empirically they will 
differ given that the family is hard-coded in this call.

Does anybody have a firmer grasp on the semantic differences between old 
APR and new APR for hostname=NULL/family=APR_INET?  If so, then perhaps 
server/config.c needs to be changed to just create an all-zeros socket 
address manually, without involving the resolver.  (Or we ask ourselves 
if the APR semantics should have changed.)


Re: resolver confusion (was "Re: Tagged the trees")

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, September 9, 2003 9:56 AM -0400 Jeff Trawick 
<tr...@attglobal.net> wrote:

> Does anybody have a firmer grasp on the semantic differences between old APR
> and new APR for hostname=NULL/family=APR_INET?  If so, then perhaps
> server/config.c needs to be changed to just create an all-zeros socket
> address manually, without involving the resolver.  (Or we ask ourselves if
> the APR semantics should have changed.)

We have to have hostname=NULL get passed to the resolver with the AI_PASSIVE 
flag in order to correctly get our own addresses.  There's no other way to do 
that at the OS level with the getaddrinfo() API, which is what 
apr_sockaddr_info_get is supposed to be wrapping on IPv6-capable boxes.  So, 
having NULL mean 'create 0.0.0.0' can't work.

As for why httpd is doing this code rather than something like:

apr_sockaddr_ip_set(&sa->addrs->host_addr, APR_ANYADDR);

beats me.  That code snippet never seemed to fit quite right in the scheme of 
things.  I think it's trying to just ensure that it's creating a 0.0.0.0 
address.  But, that's rather foolish.  A box might not have IPv4 configured, 
but only IPv6.  Surely there's a better way to represent that a specific vhost 
hasn't been configured against an IP address?  -- justin

Re: resolver confusion (was "Re: Tagged the trees")

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, September 9, 2003 9:56 AM -0400 Jeff Trawick 
<tr...@attglobal.net> wrote:

> Does anybody have a firmer grasp on the semantic differences between old APR
> and new APR for hostname=NULL/family=APR_INET?  If so, then perhaps
> server/config.c needs to be changed to just create an all-zeros socket
> address manually, without involving the resolver.  (Or we ask ourselves if
> the APR semantics should have changed.)

We have to have hostname=NULL get passed to the resolver with the AI_PASSIVE 
flag in order to correctly get our own addresses.  There's no other way to do 
that at the OS level with the getaddrinfo() API, which is what 
apr_sockaddr_info_get is supposed to be wrapping on IPv6-capable boxes.  So, 
having NULL mean 'create 0.0.0.0' can't work.

As for why httpd is doing this code rather than something like:

apr_sockaddr_ip_set(&sa->addrs->host_addr, APR_ANYADDR);

beats me.  That code snippet never seemed to fit quite right in the scheme of 
things.  I think it's trying to just ensure that it's creating a 0.0.0.0 
address.  But, that's rather foolish.  A box might not have IPv4 configured, 
but only IPv6.  Surely there's a better way to represent that a specific vhost 
hasn't been configured against an IP address?  -- justin