Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4F9CF4E0.9030109@velox.ch>
Date: Sun, 29 Apr 2012 09:59:28 +0200
From: Kaspar Brand <httpd-dev.2012@velox.ch>
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: [users@httpd] SNI with apache 2.4.1 reverse proxy
References: <4F7FDCAC.2070001@velox.ch>
 <1aa10db6-f933-45af-8b42-17b89f392bb2@iris>
 <20120410080111.GC28860@weiser.dinsnail.net>
 <20120416104526.GA22470@weiser.dinsnail.net> <4F8C064C.4010506@edelweb.fr>
 <20120416144727.GB22470@weiser.dinsnail.net> <4F8E7873.8000004@velox.ch>
 <20120423151104.GA21338@weiser.dinsnail.net>
In-Reply-To: <20120423151104.GA21338@weiser.dinsnail.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 23.04.2012 17:11, Michael Weiser wrote:
> I don't think so: I'm not directing the Proxy to connect to a different
> host. I just make it send different SNI data to the configured backend
> server and accept a different CN in the server's certificate.

I guess it boils down to the question of what the semantics of ProxyPass
are / should be. Currently, the docs say (for 2.0/2.2./2.4):

> This directive allows remote servers to be mapped into the space of 
> the local server; the local server does not act as a proxy in the 
> conventional sense, but appears to be a mirror of the remote server. 
> _path_ is the name of a local virtual path; _url_ is a partial URL for
> the remote server and cannot include a query string.

With the patch you proposed in PR 53134, the docs about ProxyPass would
have to be amended with something like: "If ProxyPreserveHost is turned
on, the host component of _url_ is used to determine what host to
connect to at the network layer, but is otherwise ignored (only the
scheme and path components are taken into account)."

Whether that is desired or not probably depends on a judgement of
possible use cases. As far as I'm concerned, I'm not convinced that
there are really good reasons for "playing the ProxyPreserveHost trick"
(neither for https nor for http, actually), but YMMV.

Kaspar