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 08:43:37 GMT

--- Comment #18 from rahul <>  2008-06-03 01:43:37 PST ---
> 1)  "port value to apr_sockaddr_info_get()?"  I don't know if it's significant
> or not for most admins - but it is one of the input values, so perhaps there is
> a reason that hasn't revealed itself to us:  It's passed to find_addresses()
> which passes it to call_resolver() which uses it with the AIX OS to set/modify
> the "servname" parameter to getaddrinfo().  I don't use AIX, but it appears
> significant to that OS.  Therefore, for portability, it should be passed.

The port we have is only one of the values going to be used (unless the range
is set to 0) so I dont think it is correct to pass it.

>From apr_sockaddr_info_get, it is used to work around a problem with AIX which
refuses a service "0" and the solution is to set it to "1". this hints that the
port name is not important (read the comments above that line too.)

> One thing that I did notice:  If we're allocating a ProxyBindAddress address
> list where one already exists (e.g. server reconfiguration via signal HUP), we
> should free any existing list before assigning a new value in the parser:
>   if (psf->bind_addr != NULL) freeaddrinfo(psf->bind_addr);
> Otherwise, we could cause a slow memory leak over time.  Reading
> getaddrinfo()'s man page reminded me of this.


> 2)  If you want to specifically allow the "ip:port+0" case, then MIN_RANGE may
> be set to equal 0.  I took your comment that setting the range so that only a
> single port was available as "not sane" to mean that you felt such should not
> be allowed.

It is not sane, so using a warning just like when MaxClients set to too low :)

>  I suggested a value of 8 so that there would always be a minimum
> of 8 worker ports available.  We still need to reject negative values for "r",
> so checking (r < some_value) still needs to be there.

This is there in the patch (r < 0)

> RE: Comment #14
> It's still faster to evaluate "1" over "r+1" even if they yield the same result
> (of 1) because r = 0.

in your case, you have a ternery embedded, I suspect the cost would be the same
in that case :)

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