I have a particular setup where what I'd like to do is reject all requests that contain a particular HTTP header (in this case, a header injected by hardware that means the request is coming from outside our private network). Here's what I thought I could do: SetEnv FOO 1 SetEnvIf Http-X-Foo .+ !FOO <Directory /foo> Allow from env=FOO </Directory> The logic being, set FOO=1, then unset FOO if the HTTP header is present, and only allow access to a resource if FOO is still present. Unfortunately, it seems that mod_env adds its values to r->subprocess_env during the fixups phase, which means that any values it sets come after those set by mod_setenvif, which runs during the post_read_request phase. Also, in this particular instance, it also means that it's too late for the auth_checker phase as well, and the request is rejected before mod_env's fixups handler even runs. The attached patch simply changes mod_env to run during the post_read_request phase, before mod_setenvif. This allows the logic I outlined above to work nicely. Now, there may be historical reasons why this isn't desired, and it might, I suppose, also cause existing users' configurations to malfunction. Still, I'd propose it as a 2.3/2.4 change, because it does enable functionality like that I outlined above, and more generally, it makes sense that all of the SetEnv* and PassEnv*, etc., directives would take effect at the same time. If this change isn't accepted, then I would strongly suggest changing the documentation regarding environment variables to indicate the order in which directives take effect; at the moment, that's not clear. In fact, the current documentation says the following, which may be true for the special purpose environment variables listed on the page, but isn't true in general for variables used in other ways (e.g., in "Allow from env"). "To make these mechanisms as flexible as possible, they are invoked by defining environment variables, typically with BrowserMatch, though SetEnv and PassEnv could also be used, for example."
Created attachment 17264 [details] run during post_read_request, before mod_setenvif
This bug has been reported a few times before, most recently as 36908. It always gets marked WON'T FIX, which is tolerable, I suppose, but then I strongly urge that the documentation be updated, in particular the section I outlined, which suggests to the reader that SetEnv and SetEnvIf take effect at the same time.
43540 patch adds SetEnv2 to mod_setenvif to fix this problem
bug #43540 http://issues.apache.org/bugzilla/show_bug.cgi?id=43540
(old ticket cleanup) It's too disruptive to change the order. The manual now states in env.html: The SetEnv directive runs late during request processing meaning that directives such as SetEnvIf and RewriteCond will not see the variables set with it.
It remains annoying that the instinctive configuration SetEnv VAR_ALPHA mydefault SetEnvIf Host example\.com VAR_ALPHA=notmydefault does not work as expected. It steals time from many developers until you notice it. And the sentence "It's too disruptive to change the order." suggests that something would have to be fundamentally revised here.
(In reply to Steven from comment #6) > It remains annoying that the instinctive configuration does not work as > expected. Maybe, but the behaviour is documented. Should the wording be improved or should something be explained elsewhere, could you please make a proposal? Also, does the following (untested) achieve what you need? SetEnvIf Host .* VAR_ALPHA=mydefault SetEnvIf Host example\.com VAR_ALPHA=notmydefault If yes, maybe it could be added as an example to the doc.