On Apr 29, 2014, at 8:41 AM, Jan Kaluža <[email protected]> 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.
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
