Return-Path: 
 <dev-return-86223-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org>
X-Original-To: apmail-httpd-dev-archive@www.apache.org
Delivered-To: apmail-httpd-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 33C2119800
	for <apmail-httpd-dev-archive@www.apache.org>;
 Fri, 15 Apr 2016 11:48:33 +0000 (UTC)
Received: (qmail 42765 invoked by uid 500); 15 Apr 2016 11:48:32 -0000
Delivered-To: apmail-httpd-dev-archive@httpd.apache.org
Received: (qmail 42698 invoked by uid 500); 15 Apr 2016 11:48:32 -0000
Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help: <mailto:dev-help@httpd.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@httpd.apache.org>
List-Post: <mailto:dev@httpd.apache.org>
List-Id: <dev.httpd.apache.org>
Delivered-To: mailing list dev@httpd.apache.org
Received: (qmail 42688 invoked by uid 99); 15 Apr 2016 11:48:32 -0000
Received: from pnap-us-west-generic-nat.apache.org (HELO
 spamd1-us-west.apache.org) (209.188.14.142)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Apr 2016 11:48:32 +0000
Received: from localhost (localhost [127.0.0.1])
	by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org)
 with ESMTP id 40ADFC0FD3
	for <dev@httpd.apache.org>; Fri, 15 Apr 2016 11:48:32 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org
X-Spam-Flag: NO
X-Spam-Score: -3.297
X-Spam-Level: 
X-Spam-Status: No, score=-3.297 tagged_above=-999 required=6.31
	tests=[RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996,
	SPF_PASS=-0.001] autolearn=disabled
Received: from mx1-lw-eu.apache.org ([10.40.0.8])
	by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new,
 port 10024)
	with ESMTP id 42CnmsFB0Z82 for <dev@httpd.apache.org>;
	Fri, 15 Apr 2016 11:48:29 +0000 (UTC)
Received: from mailserver.kippdata.de (capsella.kippdata.de [195.227.30.149])
	by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP
 id 9E8905F396
	for <dev@httpd.apache.org>; Fri, 15 Apr 2016 11:48:29 +0000 (UTC)
Received: from [10.0.110.6] ([192.168.2.104])
	by mailserver.kippdata.de (8.13.5/8.13.5) with ESMTP id u3FBmSQq029598
	for <dev@httpd.apache.org>; Fri, 15 Apr 2016 13:48:29 +0200 (CEST)
Subject: Re: Allow SSLProxy* config in <Proxy> context?
To: dev@httpd.apache.org
References: <570E220C.8090101@kippdata.de>
 <05EAB94A-2178-4CD1-B1B9-42983738AE54@sharp.fm>
 <570E8697.4050504@kippdata.de>
 <CAKQ1sVN_A+OUhhj=-gBwFy5oRvSEvuEuB4kGtr6RF8ugdcbxQw@mail.gmail.com>
 <CAKQ1sVM3xaPoVJ0pFYobBEVTsoHzQo3FtCfxLQBezwOjKLu77w@mail.gmail.com>
From: Rainer Jung <rainer.jung@kippdata.de>
Message-ID: <5710D501.3080802@kippdata.de>
Date: Fri, 15 Apr 2016 13:48:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: 
 <CAKQ1sVM3xaPoVJ0pFYobBEVTsoHzQo3FtCfxLQBezwOjKLu77w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Am 15.04.2016 um 13:30 schrieb Yann Ylavic:
> On Thu, Apr 14, 2016 at 9:57 AM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
>>
>> IIUC, the <Proxy> block is a per_dir context already, which can/could
>> accept any directive provided their ap_check_cmd_context() allows it
>> (we may need to declare a new PROXY_CONF).
>>
>> So how about making per_dir SSLProxy* directives, restricted to server
>> and <proxy> context?
>> This would let the loading (and validation) work like currently,
>> mod_ssl could still do its standalone post_config stuff (server AND
>> per_dir wise).
>>
>> At runtime, proxy_walk() would still do the merging (there may be same
>> SSLProxy* in both <VirtualHost> and <Proxy> which need merging, but
>> that would be a single one since we restrict those directives to
>> server and <proxy> context).
>>
>> Finally, if ssl_proxy_enable[_ex]() is given r->per_dir_config, it
>> could initialize the backend connection with the right context.
>
> I think I'm closed to implement this fully, not finished yet, but
> mostly not tested at all...
>
> This would have the advantage to avoid any naming convention between
> mod_ssl and mod_proxy (DN or proxy name, ...) for the admin.
> Simply put the SSLProxy* directives in <Proxy> and it works (the httpd
> way), merging parent directives when current value is uninitialized,
> creating an SSL_CTX per dir (server, vhost and/or <proxy>) for proxy
> connections to use the appropriate one.
>
> Of course all this can vanish at (self) testing time, I may have
> missed/misunderstood something which makes the whole nonsense...
> In the meantime, maybe it can avoid someone starts working on "the
> other way", unless obviously it is a better way than this one to start
> with (in which case let me know too ;).
> BTW, if I can't finish this afternoon (UTC+2), it won't be before the
> end of the week-end or next week, so any implementation is very
> welcome anyway, the more proposals, the better :)

Very cool Yann!

Rainer