httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: mod_rewrite/proxy UDS issues
Date Tue, 25 Feb 2014 12:26:53 GMT
On Mon, Feb 24, 2014 at 9:41 PM, Jim Jagielski <> wrote:
> On Feb 24, 2014, at 10:05 AM, Yann Ylavic <> wrote:
>> I use the following config :
>> <VirtualHost>
>>     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.

View raw message