On Mar 24, 2009, at 11:46 AM, William A. Rowe, Jr. wrote:
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 :)
Again looking over all this, the confusion, I think comes about because
historically you were able to pass a full URL as the 2nd arg to
ProxyPass. But when the balancer was added, you are instead passing
a "name" that looks like a URL. And the more I think about it, whether
this is optimal or not, logically it makes sense. Because what,
exactly, does a path in a balancer://foo/ *name* really mean? In the
above example, is the URL passed to the members http://hash/bang/bar ?
Do 2 balancers named balancer://foo/bar and balancer://foo/boo share
the exact same connection pool and other resources?
I think that forcing balancer://.. to always ignore paths and require
users to set paths as member definitions is the easier course of
action. So adding error-log entries which say "You added path
info to balancer://foo/ this is ignored" is likely enuff.
I'm trying to think of scenarios where paths in balancers make sense
and don't make things harder to understand... if anyone can, then
let me know :)
