httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: [PATCH] Fix settings options with ProxyPassMatch
Date Tue, 29 Apr 2014 13:29:33 GMT

On Apr 29, 2014, at 8:41 AM, Jan Kalu┼ża <jkaluza@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.

Mime
View raw message