On Wed, Apr 11, 2018 at 05:49:47PM +0200, Yann Ylavic wrote: > I agree... to both Stefan's and your points of view here :p
YOU FENCE SITTER! :) > We can hardly break existing configurations, even if they rely on a > bug (our bug...). > But another user (or the same!) may open a bug when her/his > SSLCertificate stops working as soon as any other SSL directive is > added to the second vhost (as explained by Stefan), and we should also > fix it. > > Maybe we need a global EXEC_ON_READ setting (before any vhost) to > control/ignore AP_MODULE_FLAG_ALWAYS_MERGE? > Otherwise broken users are stuck with mod_ssl < 2.4.33 (which may be > also an option for dubious compatibility issues). Seems like a poor compromise since we get lumbered with maintaining another config option and users will still have to change their configs after upgrading to 2.4.33. I feel like it should be possible to restore the old behaviour simply by disabling the implicit-SSLEngine-on in the cases where we'd never get a separate SSLSrvConfigRec before. e.g. could we suppress default-on if pks->cert_files is empty? (plus some mod_md fudge factor??) Regards, Joe
