Yes, that is right. SOME modules can grab the context for *other*
modules (proxy does this), but in general, the context is related
to *this* connection for *this* module.
> On Mar 3, 2016, at 10:30 AM, Stefan Eissing <stefan.eiss...@greenbytes.de>
> wrote:
>
>
>> 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
>
