httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: SSLSrvConfigRec shared
Date Thu, 21 Sep 2017 11:00:16 GMT
On Thu, Sep 21, 2017 at 11:48 AM, Stefan Eissing
<> wrote:
>> Am 21.09.2017 um 11:37 schrieb Yann Ylavic <>:
>> 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.


> My fix for this in mod_ssl is part of
> 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
>>> 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...

View raw message