On 24.03.2009 14:57, Jim Jagielski wrote:
>
> On Mar 24, 2009, at 9:44 AM, Ruediger Pluem wrote:
>
>> On 24.03.2009 14:28, Jim Jagielski wrote:
>>> There have been a few times when people get caught up when
>>> using ProxyPassReverse with balancers that contain a path...
>>> After all, the normal convention is everywhere you see a
>>> ProxyPass there should be a corresponding ProxyPassReverse
>>> that follows the same format. However in cases where
>>> ProxyPass contains a path, PPR doesn't work correctly...
>>>
>>> This fixes that but is also safe for the vast majority of
>>> existing sites. I plan to commit unless there are objections:
>>>
>>> Index: modules/proxy/proxy_util.c
>>> ===================================================================
>>> --- modules/proxy/proxy_util.c (revision 757753)
>>> +++ modules/proxy/proxy_util.c (working copy)
>>> @@ -1080,11 +1080,9 @@
>>> * or may not be the right one... basically, we need
>>> * to find which member actually handled this request.
>>> *
>>> - * TODO: Recover the path from real and use that
>>> - * for more exact matching
>>> */
>>> if ((strncasecmp(real, "balancer:", 9) == 0) &&
>>> - (balancer = ap_proxy_get_balancer(r->pool, sconf, real))) {
>>> + (balancer = ap_proxy_get_balancerwpath(r->pool, sconf,
>>> real))) {
>>
>> Doesn't it make more sense to cut off the path of real here to get the
>> balancer
>> instead of adding a new function to the API (which also requires a
>> minor bump,
>> but thats just nitpicking)?
>>
>
> Well, cutting off path from real is what ap_proxy_get_balancer() actually
> *does* and is what I'm trying to adjust :)
Hm. I am getting confused now. We do *not* store the path in balancer->name.
So if we do not cut it off in ap_proxy_get_balancer our strcmp will never match
correct?
Regards
Rüdiger
