On Apr 29, 2014, at 8:41 AM, Jan Kaluža <jkal...@redhat.com> wrote:
> 
> Because later we have to match the URL of request with some proxy_worker.
> 
> If you configure ProxyPassMatch like this:
> ProxyPassMatch ^/test/(\d+)/foo.jpg http://x/$1/foo.jpg
> 
> Then the proxy_worker name would be "http://x/$1/foo.jpg";.
> 
> If you receive request with URL "http://x/something/foo.jpg";, 
> ap_proxy_get_worker() will have to find out the worker with name 
> "http://x/$1/foo.jpg";. The question here is how it would do that?
> 
> The answer used in the patch is "we change the worker name to 
> http://x/*/foo.jpg"; and check if the URL ("http://x/something/foo.jpg"; in our 
> case) matches that worker.
> 
> If we store the original name with $N, we will have to find out different way 
> how to match the worker (probably emulating wildcard pattern matching)
> 
> It would be possible to store only the original name (with "$N" variables), 
> store the flag that the proxy worker is using regex and change 
> ap_proxy_strcmp_ematch() function to treat "$N" as "*", but I don't see any 
> real advantage here.

Huh???

I thought we were talking about this simple, streamlined patch that
does JUST matching/awareness of regex's, not the one which seems
to fold in a BUNCH of other semi-related stuff.

Attachment: httpd-trunk-proxypassmatch.patch
Description: Binary data


> 
>> The version I looked at had some 'use_regex' logic outside of
>> ap_proxy_get_worker(), right before we call it, in fact. Maybe
>> I'm seeing an older version of the patch?
>> 
> 
> I think that's the correct patch. It has use_regex only for creating the 
> proxy_worker to distinguish between "normal" worker and "regex" worker.
> 
> Note that "use_regex" does not influence the call of "ap_proxy_get_worker()". 
> As I said, it's used only to distinguish whether the newly created worker is 
> "normal" worker or "regex" worker.
> 
> Regards,
> Jan Kaluza

Reply via email to