httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: cvs commit: httpd-2.0/server listen.c
Date Wed, 13 Aug 2003 22:57:34 GMT
   I couldn't answer that question for sure.  Taking a quick look
through the Apache code and modules, I don't see anything.  But that
doesn't mean that some third party module doesn't depend on it.  Do the
recent changes, include allowing sa->hostname to be NULL where it didn't
before?

  From what I see in CVS now, there is only one implementation of
apr_sockaddr_info_get() which is in unix/sockaddr.c.  This calls one of
two implementation of find_addresses() (whether you have getaddrinfo()
or not).  This is where sa->hostname is being defaulted to "0.0.0.0" (
in the non-getaddrinfo() implementation).  It seems that both
implementations should be sync'ed up to produce the same results.  It
appears that defaulting to "0.0.0.0" rather than NULL would be the safer
thing to do.

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> justin@erenkrantz.com Wednesday, August 13, 2003 4:18:19 PM >>>
--On Wednesday, August 13, 2003 16:07:12 -0600 Brad Nicholes 
<BNICHOLES@novell.com> wrote:

>    I guess I don't follow here.  The problem I have is that
> alloc_listener() allows "addr" to be NULL.  Because of the lame

Okay, let me try to restate the problem:

- addr *may* be NULL when alloc_listener is invoked.  Adding a NULL
check 
before doing the strcmp would indeed fix this problem, but prevents 
listener reuse.

- We *have* to pass NULL to apr_sockaddr_info_get so that getaddrname()
can 
do the IPv6/IPv4 fail-over on its own (as it is supposed to do - httpd

can't do the guessing correctly).

- However, on *some* implementations (based on the code in CVS right
now), 
the sa->hostname returned by apr_sockaddr_info_get may be NULL or
"0.0.0.0" 
even if we passed NULL into apr_sockaddr_info_get.

What we're trying to accomplish in this code fragment is to reuse old 
walkers that are already listening on the same port.  So, this 
inconsistency means that an addr with a value of NULL *could* be
equivalent 
to NULL or "0.0.0.0" (if the OS doesn't have IPv6).  So, one of two
things 
should happen:

- We should allow NULLs in sa->hostname.  We fix up the IPv4
implementation 
to not store "0.0.0.0" in the sa->hostname field, but NULL.

- We don't allow NULLs in sa->hostname.  Then, we need to take the
'name' 
returned by getaddrinfo() and store it.  However, we would have to do
this 
resolution before we can do the walking as NULL may resolve to (say): 
'0.0.0.0' or '::'.  Only after calling apr_sockaddr_info_get would we
know 
which it resolves to.

My question was whether anything relies upon sa->hostname being a valid

value?  I don't think they should, but the sockaddr_t is part of the
public 
conn_rec.  -- justin

Mime
View raw message