httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 38019] New: - SetEnv can't be used before SetEnvIf
Date Thu, 22 Dec 2005 21:44:58 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38019>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38019

           Summary: SetEnv can't be used before SetEnvIf
           Product: Apache httpd-2
           Version: 2.3-HEAD
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: PatchAvailable
          Severity: normal
          Priority: P3
         Component: mod_env
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: chrisd@pearsoncmg.com
                CC: chrisd@pearsoncmg.com


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."

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message