"Error" is for configuration problems that should interrupt parsing.

There is no short-circuiting of <if> config sections that can never evaluate to true during the processing of a request, the if and the directives they enclose are still part of the configuration.

Too hasty, maybe error can blow up when encountered in If

After more thought, it seems to be high risk/reward tradeoff to change the behavior here.  It marginally helps configs that don't startup today, but nesting <If>, IfDefine, and Error would be regressed.

I will leave it open for others to consider, but I suggest changing the subject or otherwise clarifying

I think I'm having the same problem as bug #63146. There seems to be a lot of magic going on in the config parsing that interacts badly with <If>.

I don't really know what a good solution could look like given that I'm not an expert on the relevant limitations, but from a dumb user perspective (and to put it bluntly) it's pretty annoying to have a feature depend on secret details, and then fail silently / return bullshit / launch missiles when you run afoul of the rules you didn't know about.

If you asked 100 random programmers or system administrators what

  <If "'www' == 'x'">
    Error "www and x are equal"
  </If>

will do, I would be surprised if any of them guessed right. At a high level, my complaint is basically just that the actual behavior of <If> should more closely match the mental model of it that everyone is going to arrive with. And if that's not possible, throw a sensible error instead of quietly proceeding with a config that acts nothing like what is written.

For posterity, this is a horrendous workaround for my original problem of comparing $host to "www":

  <IfDefine www>
    Error "Constant 'www' is already defined"
  </IfDefine>

  <IfDefine !$host>
    Define $host
    <IfDefine www>
      # Do whatever
    </IfDefine>
    Undefine $host
  </IfDefine>

I don't really recommend it, but it works in a pinch.

I agree we shouldn't change the behaviour. From a C perspective it's a bit like expecting

 if (0) {
#error fail
 }


to do compile as a noop. Maybe this could be clarified in the docs for Error/Warning.

changing subject.

added some warnings in 1905793

My actual use case didn't involve Error, but ServerAlias. "Error" was just to obtain a minimal reproducible case. See bug #63146 for another real use case.

And as far as "Error" is concerned... the documentation includes the example,

  # ensure that exactly one of SSL,NOSSL is defined
  <IfDefine SSL>
  <IfDefine NOSSL>
    Error "Both SSL and NOSSL are defined.  Define only one of them."
  </IfDefine>
  </IfDefine>

which already implies that "Error" won't be executed if it's enclosed in a conditional that evaluates false. I don't think making the same assumption about <If> is too much of a stretch.

Regardless, the fundamental issue with <If> is that the user's config says one thing, but apache (quietly) ignores it and loads something else. In my case, either Error or ServerAlias get executed unconditionally, i.e. apache ignores the <If> entirely. In bug #63146, both Define statements that were intended to be mutually exclusive are executed.

I'm sure the technical details are a mess, but silently proceeding with a runtime config that (given what the user obviously intended) is so completely counter-intuituve is the worst possible failure mode for such a misconfiguation.

(In reply to Michael Orlitzky from comment #8)
> My actual use case didn't involve Error, but ServerAlias. "Error" was just
> to obtain a minimal reproducible case. See bug #63146 for another real use
> case.

For me ServerAlias inside of <If> always results in a startup failure as expected. It's not supported in any "directory" section which includes <if> already. But based on the defensive and histrionics in this report I'm not (personally) inclined to continue here.