httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: Allow SSLProxy* config in <Proxy> context?
Date Fri, 15 Apr 2016 11:48:17 GMT
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

Mime
View raw message