httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: ProxyPassReverse and paths
Date Tue, 24 Mar 2009 16:08:17 GMT

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 :)


Mime
View raw message