configuring alternate algorithms for CGI variables (yet again?)

[Jeff Trawick <tr...@gmail.com>]

Synopsis:

CGIVariable variable keyword-applicable-to-variable

e.g.,

CGIVariable REQUEST_URI from-active-request|from-request-line

(Please oh please think of a better directive name :) )

from-active-request:  REQUEST_URI will be set from the active request
(possibly a subrequest).
from-request-line (default):  REQUEST_URI will be set from the original
request line received from the client.

This kind of setting would be part of core's request_config, and would be
consulted as appropriate by different code bundled with httpd
(ap_add_cgi_vars(), mod_proxy_FOO, etc.) or even third-party modules
(mod_xSGI), like the CGIPassAuth directive.

The problem at hand: Make REQUEST_URI in a script invoked via SSI represent
the script invocation, not the original request.  It worked this way in
very early 2.0.x for a while, until https://archive.apache.org/gnats/7580
which restored the 1.3 behavior.  The current value in httpd is a pain for
a particular customer app that can be used with httpd 2.4 or with a
different web server.  (FWIW, ssl_var_lookup("REQUEST_URI") uses r->uri; I
didn't even know it cared.)

Generally: An more obvious variable that could use such configuration is
PATH_INFO; this is implemented (inconsistently) in multiple proxy backends,
and configured using an "envvar" that isn't effective if you do the obvious
thing, SetEnv.  While PATH_INFO is out of scope for me for the moment, I'd
like to control how REQUEST_URI is set in a manner that is extensible to
other CGI variables in the future.

Thoughts?

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/