Am 15.04.2016 um 13:30 schrieb Yann Ylavic:
On Thu, Apr 14, 2016 at 9:57 AM, Yann Ylavic <ylavic....@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
