On Thu, Sep 21, 2017 at 11:48 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > >> Am 21.09.2017 um 11:37 schrieb Yann Ylavic <ylavic....@gmail.com>: >> >> If the module defines its own server_config_create() which allocates >> one, each vhost will have its own, and the module's >> server_config_merge() can do whatever needs to for the members of the >> config (pointer copy, shallow/deep copy, ...). > > Yes, but only *iff* there is every a directive of that module used in > a VirtualHost.
OK, I see know, thanks. I'd call that a premature optimization though, even if it matured for decades :) Only the module knows what to do when merging, so I think the core config should still call config_create() and config_merge() for those, precisely because post_config() is always called. Modules also know how to merge configs that do nothing (usually), with all those _set members all over the place, so it should work (untested ;) even if it may consume more (not that much I think) initial memory for large confs. > > The assumption here is that module configs at that point-in-time are > read-only. Which is not really true since several modules make changes > in the post_config phase that happens afterwards. Agreed. > > My fix for this in mod_ssl is part of > http://svn.apache.org/viewvc?view=revision&revision=1809037 > which calls ssl_config_server_uniq() once at the post_init phase > for each server. Or maybe do the right thing (IMHO) in core. >>> >>> Now, are you speaking of changing that for all modules? Add a flag to >>> "struct module" >>> or solve it in mod_ssl post_config? >> >> Of course not, create/merge process per module can already do that, up >> to the module to do what it needs (correctly). Finally, maybe :) It could be "suprising" for any module. Let's see what others think...
