The only time this needs to be off is when using the Balancer Manager to adjust Balancers and Workers... As such, I think I was a bit over-eager in what conf-> fields needed to be worried about.
Here's the problem: If a balancer is defined in the top-level server, then it is inherited by all vhosts. But balancers themselves are server-specific. Normally, this makes no difference, but when dynamically changing balancer and worker parameters, you want to be able to ensure that you are only changing the params for a specific balancer/worker associated with that particular server (vhost) and not for "everyone", which is the potential since those params are stored in shared mem. By ensuring that each server has their own "private" set of balancers and workers, we avoid the problem. On Dec 17, 2012, at 5:03 AM, Graham Leggett <[email protected]> wrote: > On 17 Dec 2012, at 11:23 AM, Rainer Jung <[email protected]> wrote: > >> That's the whole purpose of the "ProxyPassInherit Off" setting. If you >> switch the global setting from "On" to "Off", then global proxy targets >> and workers are not merged to any vhost. If you switch to "Off" only in >> a VHost, then only that VHost does not inherit (merge) the globally >> defined ones. If you switch to "Off" globally but again to "On" in a >> VHost, then only those VHosts will inherit. > > Ok, I see this now, but only after reading the above paragraph three times > and the code a few times more. > > This is a special edge case that goes against the typical behaviour of all > the other directives in the server, and as a result will confuse the life out > of any admin who hasn't seen this before. The documentation at > http://httpd.apache.org/docs/trunk/mod/mod_proxy.html#proxypassinherit needs > to define two things: > > - An accurate list of the exact directives affected by this directive. > "ProxyPass Balancers and Workers" is not accurate enough. > > - An accurate description of the "issues and inconsistent behaviour" that the > admin is likely to experience if they don't turn this directive off. > > The admin is probably going to find this directive after searching for a > problem in google, we need to make sure that google search is going to lead > directly to this directive. > > Regards, > Graham > -- >
