httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 44806] Set the IP address+port used for backend proxy requests.
Date Tue, 03 Jun 2008 05:40:58 GMT

--- Comment #13 from rahul <>  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 -
> ).  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?

> +
> +    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:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message