On Fri, Nov 28, 2014 at 1:56 PM, Eric Covener <cove...@gmail.com> wrote: > Did this become unnecessary when SetHandler/AddHandler support was > added for proxy:unix:/ ... configuration?
I think both are orthogonals. One can use <Proxy "unix:/tmp/backend.sock|http://localhost/...> to declare a worker whose connections will be reusable by : 1.Set/AddHandler "unix:/tmp/backend.sock|http://localhost/..."; 2. RewriteRule ... [H=unix:/tmp/backend.sock|http://localhost/...] (supposedly) 3. RewriteRule ... "http://localhost/.."; [P] But not by : 4. RewriteRule ... "unix:/tmp/backend.sock|http://localhost/..."; [P] Yes 1. and 2. are two nice/efficient "shortcut" alternatives. But I find 3. vs 4. quite confusing, proxying via RewriteRule is often used (and even very useful thanks to RewriteCond decision), so we should either document on that, or fix it. I also find the idea of having an optional function between mod_proxy (provider) and mod_rewrite quite useful, since there is no point in using a [P] or [H=proxy:...] rules without mod_proxy loaded. The failure to retrieve this proxy optional function could be detected at init time to raise an error if any [P] or [H=proxy:...] is configured. After re-reading this thread, I would now rather propose that this optional function be downright ap_proxy_declare_worker(). Thus the proxy worker would be automagically declared with the RewriteRule at init time, and the run time could use the available proxy_worker struct directly to do its [P] job. Maybe that's what Jim was thinking about as a "non-obvious but elegant solution" where "2 workers map onto the same one", back in February 25... Regards, Yann.
