https://issues.apache.org/bugzilla/show_bug.cgi?id=44806
--- Comment #13 from rahul <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
