> -----Original Message----- > From: Joe Orton [mailto:[email protected]] > Sent: Dienstag, 24. Juli 2012 10:20 > To: [email protected] > Subject: Re: ProxyBlock question > > On Tue, Jul 24, 2012 at 07:55:27AM +0000, Plüm, Rüdiger, Vodafone Group > wrote: > > Thanks. The patch reminded me of a special situation where the patch > > might not be suitable: If the forward proxy just forwards everything > > to the next proxy e.g. because it cannot do DNS lookups of the target > > URL's > > Exactly my thought. So in presence of a forward proxy, the "least > worst" option is probably to omit the DNS lookup and only do the string > comparison against the ->noproxies list? Doing a (possibly slow to > timeout) DNS lookup just in case could impose a horrible performance > hit.
I think in trunk ap_proxy_checkproxyblock already does the correct thing. It only compares the addresses if the DNS lookup for the ProxyBlock was successful during startup / configuration. The issue with ap_proxy_checkproxyblock is that it expects the host to compare as a apr_sockaddr_t type which would force us to do the possible bad DNS lookup before calling ap_proxy_checkproxyblock. So apart from the question if we can generate a fake apr_sockaddr_t variable which contains only the name but not the IP it would be handy to know if there are any ProxyBlock members for which we had a successful DNS lookup. OTOH this means nothing as the ProxyBlock might contain hostname that could be resolved successfully via e.g. a hosts file like localhost or something else. So after this rant I come to the conclusion that your proposed approach is the best: Only compare the names and not the IP's in the proxy case. Regards Rüdiger
