On Mon, Feb 24, 2014 at 9:41 PM, Jim Jagielski <[email protected]> wrote:
>
> On Feb 24, 2014, at 10:05 AM, Yann Ylavic <[email protected]> wrote:
>
>> I use the following config :
>>
>> <VirtualHost 127.0.0.1:60080>
>> ServerName localhost:60080
>>
>> RewriteEngine on
>> RewriteRule "^/(.*)$" "unix:/tmp/backend.sock|http://localhost/$1" [P,NE]
>>
>> <Proxy "unix:/tmp/backend.sock|http://localhost" disablereuse=off>
>> </Proxy>
>> </VirtualHost>
>>
>
> Why the <Proxy> container? What is that designed to do
> or what is it there for? I'm pretty sure that's the
> issue.
>
> You are just trying to Proxy all requests to the socket at
> /tmp/backend.sock, right?
>
Right, but this config has no other purpose than testing that one can
use a RewriteRule and a <Proxy> declaration for UDS backend
connections to be reusable (this one is with the http scheme, but it
could be fcgi or any other proxy scheme...), so that I can give my +1
to STATUS ;)
Should this simply work?
If so, my point is that it does not currently because mod_rewrite
fully-qualifies the expanded URL ("unix:...|scheme:...") and hence
rewrites r->filename to
"proxy:http://localhost:60080/unix:...|scheme:.." (where
"http://localhost:60080/" is from the requested URL, as per
ap_get_server_name() and friends).
Shouldn't r->filename be simply "proxy:unix:...|scheme:.." when
mod_rewrite leaves?
This does does affect the "reverse" worker because
ap_proxy_pre_request() uses ap_strchr() to find the "unix:" scheme and
extract the "uds_path" note, but !strncmp(r->filename, "proxy:unix:",
11) wouldn't work (although safer IMHO).
My second point is that ap_proxy_pre_request() does not deal with the
UDS URL but for the "reverse" worker, so it will never find any
declared worker.
I agree this may be out of scope since the primary goal was to deal
with the default worker, and that works.
This thread would just become a request for future enhancement, and I
should go +1 for now...
If the scope is still open, I can propose a new patch with a new
ap_proxy_worker_url() function that splits the URL into separate
UDS/worker parts (when applicable, the inverse of
ap_proxy_worker_name), usable wherever needed (mod_proxy, proxy_util
and mod_rewrite if made optional), since this work has to be done at
several places for declared workers to be reachable with mod_rewrite.