httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <chr...@pearsoncmg.com>
Subject [PATCH 38019, 36908] make SetEnv run during post_read_req
Date Thu, 22 Dec 2005 22:18:05 GMT
Hi --

   Well, this may be a sore point, but I'll tackle it anyway,
so apologies in advance.  The fact that environment variables
created with SetEnv are applied during the fixups phase,
while SetEnvIf creates its variables during the post_read_request
and header_parser phases, does make my life a little more
painful.

   This has been raised in various bug reports, including #36908
and #35611.  These are marked "won't fix", with the explanation
that SetEnv is intended for use by content generators like CGI
scripts.

   However, as I've described in a new bug (sorry!), #38019,
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.

   I attach a patch to the bug report in #38019 that simply moves
mod_env's handler up to the post_read_request phase, ahead of
mod_setenvif.

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

This section in particular, to my mind, clearly implies to the reader
that SetEnv and SetEnvIf take effect at the same time.  So does
the section on the Allow direction from mod_authz_host, which says:

  "The third format of the arguments to the Allow directive allows
   access to the server to be controlled based on the existence of an
   _environment_variable_. When Allow from env=env-variable is
   specified, then the request is allowed access if the environment
   variable env-variable exists. The server provides the ability to
   set environment variables in a flexible way based on characteristics
   of the client request using the directives provided by mod_setenvif."

The link to the "Environment Variables" page, and the wording,
imply that while mod_setenvif directives may be used to control
access based on request characteristics, that's not the only
way it could work, and other mechanisms for setting environment
variables should work too.

   If it's going to stay the way it is now for historical and
user support reasons, let me know and I'll try to write
something more obvious for docs/manual/env.xml, mod/mod_env.xml,
mod/mod_authz_host.xml, etc.

Thanks!

Chris.

-- 
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B


Mime
View raw message