Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of ylavic.dev@gmail.com designates
 209.85.213.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALK=YjPyzxCHQG4-CFfpwxJVo1Ey3TrewZMFTxCJMBf-2XLv7A@mail.gmail.com>
References: 
 <CAKQ1sVN=WT62XQ5jqY7Sp_n3P+Quy+mwNd26FFPiXoGzRxWQCQ@mail.gmail.com>
	<9C8824FA-A1C5-4F2C-A057-61F47809039A@jaguNET.com>
	<CAKQ1sVNjbUyv0cT-Ln1NYgyWxj6DoGNNLWL77jsfp4KVy6Zi=A@mail.gmail.com>
	<CE7E2476-9EF7-4CE2-99FB-56EF6E773559@jaguNET.com>
	<CAKQ1sVNr4w_-Qc0rG0X=NU2ffj=crDoctu1DX6X_uMU1d06Lqw@mail.gmail.com>
	<7AF9BD7E-625C-415B-8E1B-337C4D5A2D38@jaguNET.com>
	<CAKQ1sVOH6uD7v6BV8y+_yWuF4KjKBKWXa6CJJW1z08KC1HxSPw@mail.gmail.com>
	<CAKQ1sVNhQ0CZy1ytB5DKpeh9Y=-MvakyHQ=qGEwcK7-dZ6-=1g@mail.gmail.com>
	<CAKQ1sVOcwPG1Vs9YA2udQjFTCUbXj1=CFM=0m4vbUT2qCzHvAQ@mail.gmail.com>
	<AB69611A-B387-4268-AD9A-ECFA907A5D37@jaguNET.com>
	<EC260FBB-43D3-42A3-9273-EFB09ABBE10F@jaguNET.com>
	<CAKQ1sVMsoinNfViXGJZUNb9=n+e8RH_-d1wHJLm-0L9kUTxDzQ@mail.gmail.com>
	<CAKQ1sVMPSd7VqRm4sGEKWZJQWaTaMbCcNj9N=76o8pHvf04m-w@mail.gmail.com>
	<CAKQ1sVNPsZrtJ25Pn0ETQ4oX-gwVQSLYQRgA+GzC2kKXPHPZ9A@mail.gmail.com>
	<CAKQ1sVPF=GN6t6q4==rcyEdN1kD1McKE2j1Hvy-CcjriU6AeVA@mail.gmail.com>
	<CALK=YjPyzxCHQG4-CFfpwxJVo1Ey3TrewZMFTxCJMBf-2XLv7A@mail.gmail.com>
Date: Sun, 30 Nov 2014 23:48:00 +0100
Message-ID: 
 <CAKQ1sVNvKP47pvR3tPFJ1NwxMMPAD0Atmp62N-7VdArjUBNJcw@mail.gmail.com>
Subject: Re: mod_rewrite/proxy UDS issues
From: Yann Ylavic <ylavic.dev@gmail.com>
To: httpd <dev@httpd.apache.org>
Content-Type: text/plain; charset=UTF-8

On Fri, Nov 28, 2014 at 1:56 PM, Eric Covener <covener@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.