> 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
