On Mon, Feb 24, 2014 at 9:41 PM, Jim Jagielski <j...@jagunet.com> wrote: > > On Feb 24, 2014, at 10:05 AM, Yann Ylavic <ylavic....@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). 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.