Jim Jagielski wrote:
On 2nd thought.... the whole idea of a balancer itself incorporating a path in conjunction with each ind. members also possibly having one is a big can of worms. Need to mull this over...
Let me try mind-mapping this out - please sanity check a whole group of assumptions. (And I'm not surprised, I had the same reaction after I thought I had the right patch, and realized this is much more tangled.) .... <Proxy balancer://foo/bar/> BalancerMember http://hash/bang/ BalancerMember http://backup/app2/ ProxyPass /app/ balancer://foo/bar What does <Proxy URL /bar/ mean in this context? Can you have a Member which is on one <Proxy > balancer block of balancer://foo and not in the another with another URL? This is impossible today due to the fact that the balancer set struct doesn't contain a URI member at all. Is this construct interesting for other directives? I suspect so. I don't think that <Proxy > URL's are valid for declaring BalancerMember's; my gut instinct is to WARN in 2.2 and to fail parsing this in 2.3. Now let's look at the ProxyPass[reverse] - what do the directives above do with a request to /app/login ? This pretty clearly maps to either http://hash/bang/bar/login (or http://backup/app2/bar/login) ... right? The reverse must strip the balancer member target, including URL, PLUS the RHS URL expression of the ProxyPassReverse. Sanity check this please, because we can't fix it until we understand what it was meant to do :)
