> Am 23.12.2017 um 12:34 schrieb Yann Ylavic <ylavic....@gmail.com>: > > On Sat, Dec 23, 2017 at 9:00 AM, Nick Kew <n...@apache.org> wrote: >> On Sat, 2017-12-23 at 08:20 +0100, Stefan Eissing wrote: >> >>>> Ugh. Fine for trunk, but that's a lot of complexity to foist on >>>> a stable branch. A module would not only need to check MMN, >>>> but also implement fallback behaviour if there are no flags. >>>> So why not KISS and stick with that fallback for all 2.4? >>> >>> Not sure, I parse that. Any module that does nothing continues to >>> see the same behaviour than before. Where does the complexity >>> arrive? >> >> But a module cannot ever *use* it without checking MMN >> *AND* implementing fallback behaviour for being loaded >> into an httpd built with the old struct - and consequently >> old API and ABI. >> >> That's bad enough to work through once, let alone maintain longer-term! >> >> Whereas the fallback, by definition, works in all cases. > > Right, but hence nothing prevents the modules from implementing the > fallback only, just as if "flags" were not in 2.4.x. > It's not like depending on the MMN is mandatory. > > It seems that no module really needed it until mod_md, or they already > implemented the fallback. > If we make it to 2.4.next for mod_md needs (which anyway requires > mod_ssl 2.4.next), at least it simplifies the code in mod_ssl...
Any module that writes to its config records in a post_config hook is in danger of having shared instances between vhosts. Only when directives of the module in the vhost are used, do they have a unique config record instance. There is workaround code in mod_md and I was writing that for mod_ssl as Yann came with this flag solution. So, current mod_ssl does not have a workaround and will not work in case someone uses the SSLEngine *:443 and uses no SSL* directives in vhosts. If "SSLEngine on" or other directives are used, that vhost has a unique instance of its mod_ssl config record. Very subtle. I think this really is a bug in our runtime. The flag was invented just for precaution, in case a module would rely on the no-copy behaviour. That is really close to saying: we will not fix any more bugs in 2.4.x as someone could rely on it. >> Agreed, post-config per-server stuff is clumsy: I have a distant >> memory from 2.0 days of hacking some ugly workaround, though the >> details elude me. But wouldn't it make more sense to review that >> in 2.5/trunk rather than the stable branch? > > It shouldn't hurt in 2.4, IMHO. I agree. I also think the bugfix without flag could have gone to 2.4.
