On Tue, Feb 25, 2014 at 1:26 PM, Yann Ylavic <[email protected]> wrote: > 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).
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.
