I believe we can improve the current interworking between mod_proxy and mod_ssl somewhat. Without repeating the current dance of calling optional functions here, I see the following things that can be done:
1. Have an "outgoing" flag in conn_rec that makes clear a connection is going from the server to somewhere else. What this achieves is that all pre_connection hooks can easily see they should not apply their incoming configuration for outgoing connections. This would mean for example, that mod_ssl would not try to setup SSL for http: proxy connection that came through an incoming https: server_rec. The explicit "ssl_engine_set(c, 0)" would no longer be needed. 2. Have a new "ap_hook_config_connection(c, per_dir_config)" that runs before "pre_connection" hook to attach the configuration o use for a connection. For connection reuse, this may be invoked more than once on a connection and any previous config attached needs to be discarded. This is needed to replace a r->per_dir_config previously used when r goes out of scope. We could allow the per_dir_config == NULL and call this also for incoming connections. Not sure if this is needed. 3. Have a "require_ssl" flag in conn_rec that makes clear a connection needs to be encrypted. This let's mod_ssl know that it should check the config for the connection if it should engage on it. It also makes clear that a connection - after pre_connection() - with "c->require_ssl" and "ap_ssl_conn_is_ssl(c) == 0" is not valid and needs to be denied. We could set "c->require_ssl = 1" on incoming connections where "Listen <port> https" is configured. That has the potential to break existing configurations out there, so it might not be worth it. If you have an opinion or another idea how to do this, I would very much appreciate to hear it. Based on the feedback I will make start an implementation of this and see if this completely solves the OPTIONAL function dependencies. Thanks, Stefan
