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??)