httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: Allow SSLProxy* config in <Proxy> context?
Date Fri, 15 Apr 2016 11:30:35 GMT
On Thu, Apr 14, 2016 at 9:57 AM, Yann Ylavic <> 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 :)


View raw message