http://www.ai.mit.edu/xperimental/run-scripts.html
That file also contains a pointer to the code which implements all this, as
a patch to NCSA httpd 1.0. I'm also forwarding some comments on Rich
Brandwein's proposal (which seems to me to be basically in the same spirit)
under separate cover.
The RunScripts option
I've implemented a new option, 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.
What it does
The 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:
*) .../some_dir/foo/bar/zot
*) .../some_dir/foo?some+query+args
*) HTTP POSTs to .../some_dir/foo
*) HTTP GETs to .../some_dir/foo unless an actual file named
.../some_dir/foo is sitting in the file system alongside
.../some_dir/foo.doit.
If such a file does exist, it will be retrieved for parameterless
GETs, and the script will not be invoked. This allows 'coversheets'
for ISINDEX documents to be put in a separate file, which is an
occasional minor convenience.
Giving a script the .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.
Note also that the .doit and .nph extensions are *not* visible to clients.
This is so that pre-existing files and directories can be turned into
scripts, and vice versa, without changing all references to them as well.
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.
Compatibility with existing stuff
The 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.
*) The prohibitions on retrieval of certain files apply even in directories
where 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.
If people would like to play around with this, and don't mind experimenting
with unsupported software, then the code is available --- see the URL above.
rst