On Wed, Feb 22, 2017 at 1:04 AM, Nick Kew <n...@apache.org> wrote: > On Tue, 2017-02-21 at 21:58 +0000, Joe Orton wrote: > >> Any reason <IfDirective> is a bad idea, so we can do that more cleanly >> (... in a couple of decades time)? > > One reason it might be a very bad idea: user confusion! > > I'm thinking of the track record of <IfModule> here. > Our support fora are full of users who have seen it in > default/shipped config and docs, and treat it as some > magic incantation they need. They end up with a problem > "why doesn't Foo work?", which they bring to our fora > after many hours of tearing their hair. The usual answer: > Get rid of all the <IfModule> crap, to stop suppressing > the error message you need!
That speaks to our docs/conf/* tree, right? Not the existence of the <IfModule > directive ... I'm guessing you don't support eliminating that feature in the future? I was more concerned about our support for <IfVersion >... I'd really like to see mod_version go away in 2.next and force the availability of that feature so that .conf authors are assured of it's presence moving forwards. An issue is that this is needed to let users devs toggle specific tests based on patch level. Right now, testing requires a backport, which doesn't vary by the httpd version, and only rarely varies by <IfModule >. This proposal makes introducing the tests upon adding a feature to trunk painless; the test is accessible from the moment the directive is backported. If you want to propose an "<IfModule > considered harmful" caution in the docs (which we can borrow or point to for the <IfDirective > docs) ... that could be helpful. It often indicates that the user's conf was not thought out, and that it is subject to unexpected behavior changes if a module is loaded or commented out. That doesn't mean these serve no purpose.
