> 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