RunScripts, to the Allow
directive of access.conf and .htaccess files.
This option allows the server maintainer to designate certain directories
as containing both scripts and ordinary files, and to have the server be
able to retrieve both from those (and only those) directories. A pointer
to the patch itself is at the bottom of this file.
(Note that as of 1.3, the standard daemon provides this capability in
a somewhat different form, via ExecCGI. The difference
between RunScripts and ExecCGI is that the
latter effectively requires URLs invoking CGI scripts to all end in a
designated suffix, which makes it a little difficult to turn an
existing file into a CGI script, or vice versa).
RunScripts option allows scripts to be run from any
directory where the server might find ordinary files, whether those
directories are subdirectories of SERVER_ROOT, a user's
public_html area, an Aliased directory, or
whatever, so long as RunScripts is enabled for the directory
in question. It may be enabled (or disabled) for a particular directory
and its subdirectories via Options directives in
access.conf in the usual way, and overrides via
.htaccess files may likewise be permitted or disallowed as
usual.
(In fact, you will have to edit these files to tell the daemon
which directories you want RunScripts to apply to, unless they
already say Options All).
Having scripts and ordinary files in the same directory raises the question of how to tell which is which. That's resolved by a naming convention, as follows:
If a file named .../some_dir/foo.doit or
.../some_dir/foo.nph is placed in a directory
.../some_dir which has RunScripts enabled, the
server will attempt to run it as a CGI script to handle HTTP GETs and POSTs
to URLs of the form:
.nph extension instead of
.doit has exactly the same effect as making its name start
with nph-, namely, that it has complete control of the
connection back to the client, and is therefore required to generate all
relevant HTTP and MIME headers. The only functional difference between
supplying nph as a prefix vs. as an extension is that
in the latter case, implementation details of the script aren't wired into
the URL.
One last special case --- .doit and .nph files
cannot be retrieved directly. That is, an attempt to retrieve
.../some_dir/foo.doit will fail even if the file does exist,
and an attempt to retrieve .../some_dir/foo would invoke
it as a script. Attempts to retrieve Emacs
backup or auto-save files (i.e., those ending in '~' or '#') will likewise
fail, and all of these files are left out of automatically-generated
directory lists. This is an attempt on my part to make sure people don't
export code without knowing it, which can be a potential security risk.
RunScripts patch has no effect on the behavior of
ScriptAlias at all. This means that a
ScriptAlias to some directory and an Alias to
the same directory have different effects, even if that directory has
RunScripts enabled. Different naming conventions are in
effect (when looking for scripts in ScriptAliased space, the
server does not use the .doit or .nph suffixes),
attempts to retrieve ordinary files from ScriptAliased space
will fail, and of course, the RunScripts option is not
required to run scripts from a URL covered by a ScriptAlias.
There are two known incompatibilities, both minor (at least as I see them):
Options All means
something different with the patch installed, since All
includes RunScripts.
The only way to do this back-compatibly is to have multiple levels of
all-inclusive keywords --- as on certain Unices, in which stty
all shows every tty mode setting you ever heard of, while
stty everything shows you the rest of them.
RunScripts is off. The intention here
is that if some malign influence arranges for a .htaccess
file to appear in some directory which says Options
Indexes, they don't then get to cruise the scripts in that
directory for something useful while waiting for the site maintainer
to remove the thing.