On Wed, Mar 2, 2016 at 5:20 PM, Graham Leggett <minf...@sharp.fm> wrote: > On 02 Mar 2016, at 2:26 AM, Yann Ylavic <ylavic....@gmail.com> wrote: > >>>> Would it make sense to add a vector of contexts that same way we have a >>>> vector of configs, one slot for each module, which will allow any module >>>> to add a context of it’s own to conn_rec without having to extend conn_rec? >>> >>> Can't the existing ap_[gs]et_module_config(c->conn_config, ...) be >>> used for that purpose? >> >> I mean, put the context in the module config? > > If we can it would be great - but is there an API guarantee that the memory > pointed to by the config is a per-connection copy of the config, and not the > raw underlying server wide config instead?
Hmm, not sure to follow... The server_config is indeed pconf wide, per_dir_config is either pconf (untouched) or request (merges) wide, but conn_config and request_config are to be allocated explicitly by each module on the relevant pool, nothing automagic for them AFAICT. Would you like a per conn/request context which is automatically allocated for all the modules, and which does not collide with the existing conn/request configs eventually used by the modules? Where would ap_get_module_context(c->conn_context, <themodule>) be called from, in some "core" code or by each module? In the former case I'd see the need for it (I suspect this is what you want). But otherwise it could be handled by each module in its own _config. Hard to say w/o more details or code... FWIW, the http_module has no conn/request_config so far, couldn't you simply use: ctx = ap_get_module_config(c->conn_config, &http_module) in the ap_process_http_connection() hook? Regards, Yann.
