Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Subject: DO NOT REPLY [Bug 44806] Set the IP address+port used for backend
 proxy requests.
In-Reply-To: <bug-44806-7868@https.issues.apache.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Message-Id: <20080603054058.CFCC4234C12C@brutus.apache.org>
Date: Mon,  2 Jun 2008 22:40:58 -0700 (PDT)

https://issues.apache.org/bugzilla/show_bug.cgi?id=44806


--- Comment #13 from rahul <rahul@sun.com>  2008-06-02 22:40:57 PST ---
(In reply to comment #10)
> 1)  "Range" value:  Checking for (r < 1) needs to be done(*).  It's possible
> that an admin could specify "ip:port+-range" and get a negative value.  Noting
> that a range of zero is "not useful," perhaps we need to set a minimum value
> for the range parameter?  In current parsing, not specifying a range at all
> does default it to a single port.  The question is:  What is a suitable
> default?  I'm thinking that it could be one of the following:

My thinking is that if the admin did not specify a range, and a port is given,
then it is a configuration error, as there is a good chance that the admin did
not understand the implications of restricting the port to a single value.
(Note that Admin can still force the issue by setting port+0 as range if he
wants it.)

On the other hand, if a port was not specified, then the system selects a free
port for us so a second try is not needed any more. This is the reason
bind_range is set to 1 in this case.


> 2)  "Address" value:  In the latest version, we're storing the address(es)
> returned by the apr_sockaddr_info_get() function.  By itself, I don't have a
> problem with that and thought that something like that should be done. 
> However, there are two issues with the step:
> 
> a)  We're fixing an address, but haven't checked to see if it was the ONLY
> address that the hostname resolved to.  In my original suggestion, we would
> need to make certain that DNS resolution produces a unique address (for a given
> address family).  I'm willing to DROP THAT REQUIREMENT, but then we must note
> in the documentation that should a hostname resolve to more than one address,
> all addresses returned may be used.  Dropping the uniqueness requirement per AF
> does make the parsing code simpler.  (If dropped, I think parsing might be
> finished.)
> 
> b)  Should there be multiple addresses because there's multiple address
> families (e.g. IPv4 and IPv6), we need to try an address in the same family as
> the destination.  It would be a problem if we store the IPv6 address (as first)
> and try to reach an IPv4-only site when we ignore the IPv4 address available
> for the hostname we're binding to because we're not looping through the
> alternatives.  Apr_sockaddr_info_get() is returning ALL matching addresses, but
> in proxy_util.c, it looks as if we're using only the first one and not checking
> to see if we have a reachable address family combination of source and
> destination, and when not, trying another address/AF combination.  Since at a
> point before the patch, we've already set "backend_addr" (the destination) and
> have "backend_addr->family" available, I think we need to compare these:
> 
> +                local_addr = conf->bind_addr;
> >> if (backend_addr->family != local_addr->family) { /* connection won't work */
>       TRY ANOTHER ADDRESS from bind_addr, if available.
> We may need another loop beyond the port+range loop.  Inner loop or outer is
> your choice, but I think an inner loop is more efficient.
> 
> c)  Should we pass the port value to apr_sockaddr_info_get()?  I don't think it
> makes a difference, but if I remember getaddrinfo() correctly (called 2
> routines deep from here), it may - in that it allows us to filter out certain
> returns of information.  (Cf. - bug reported for INN 2.4.3 that was returning
> each IP address 3 times -
> http://groups.google.com/group/news.software.nntp/browse_thread/thread/260a927ec3f5686c/bf6d6d2854dfb0ae?#bf6d6d2854dfb0ae
> ).  I note that the fix for the INN bug is already in the Apache code, but
> maybe the port number is also needed to avoid the duplication issue?

>From that post, it seems the fix is to specify the protocol? how is specifying
port useful?

[snip]
> +
> +    psf->bind_port = port;
> +    /* If there didn't exist a port then there was no range either. so we have
> the
> +     * starting value 0 for r when no port was specified.*/
> ++   psf->bind_range = min( port ? MIN_RANGE : 1, r + 1 );

see above (top) explanation, I dont think we should use a MIN_RANGE (if at all,
we should check the range value, and if less than MIN_RANGE, warn the user.)

> +    psf->bind_idx = 0;
> +    psf->bindopt_set = 1;
> +    return NULL;
> 


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org