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 :) Regards, Yann.
