httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: mod_rewrite/proxy UDS issues
Date Tue, 25 Feb 2014 12:34:27 GMT
On Tue, Feb 25, 2014 at 1:26 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
> On Mon, Feb 24, 2014 at 9:41 PM, Jim Jagielski <jim@jagunet.com> wrote:
>>
>> On Feb 24, 2014, at 10:05 AM, Yann Ylavic <ylavic.dev@gmail.com> 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).

Please note that the above does not depend on the <Proxy> declaration,
the same happens with or without it.

>
> 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.

Mime
View raw message