> Am 03.03.2016 um 16:21 schrieb Yann Ylavic <ylavic....@gmail.com>:
> 
> On Thu, Mar 3, 2016 at 3:57 PM, Jim Jagielski <j...@jagunet.com> wrote:
>>    /** Config vector containing pointers to connections per-server
>>     *  config structures. */
>>    struct ap_conf_vector_t *conn_config;
> 
> Yes, this is opaque, and turns out to be a implemented as void**.
> We could even make it a struct if we'd want 2 "batons" per module,
> with something like:
>  struct ap_conf_vector_t {
>      void *config;
>      void *context;
>  };
> in server/config.c, without breaking the API (since it is opaque).
> And then let ap_get_module_config/context() use the existing
> conn/request_config.
> Another vector might be better/simpler/safer, though.
> 
> Still I'm not sure to understand the use case for now...

I think we confuse ourselves with the wording here. As I understand it, almost 
all modules store connection context information in that vector. In that sense, 
it is *their* internal configuration for the connection, not necessarily the 
same as is stored at other config locations, such as server or request.

Some ap_conf_vectors are populated by the runtime for all modules participating 
(like server_rec->module_config), some are not. The ones in conn_rec 
->conn_config are only directly set by a module and the module determines what 
does there.
And what a module stores there can be a process wide singleton or something 
with the lifetime of the conn_rec->pool, it's up to the module.

That is how I understand it. And I hope that I'm right, but if not, please 
explain what I missed, since mod_http2 makes very much use of this...

-Stefan

Reply via email to