httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, Vodafone Group <>
Subject RE: ProxyBlock question
Date Tue, 24 Jul 2012 08:42:34 GMT

> -----Original Message-----
> From: Joe Orton []
> Sent: Dienstag, 24. Juli 2012 10:20
> To:
> 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
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
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.



View raw message