More CGI Comments --- scripts, suffixes and such... (Robert S. Thau)
From: (Robert S. Thau)
Date: Sat, 8 Jan 94 17:03:19 EST
Message-id: <9401082203.AA08999@volterra>
In-reply-to:'s message of Sat, 8 Jan 94 14:04:24 EST <9401081904.AA23102@hotsand.dacsand>
Subject: More CGI Comments --- scripts, suffixes and such...
Content-Length: 2731

   ... [reformatted to fit on 80-character windows]

   3) Because of (1), (2) and my general preferences of arranging files, I
   find it would be much easier to identify executables on the server side
   by being able to use a server defined suffix (notwithstanding the
   previous arguments against this) for these files (e.g., .cgi).


   Rich Brandwein
   AT&T Bell Labs

A note of agreement --- I implemented a suffix-based scheme myself a while
ago for some of the same reasons, and I've been running with it for a few
weeks now.  If you feel comfortable playing with unsupported software, you
could take a look at my hacks, which I've made available as a source patch
to NCSA httpd 1.0.  See

for documentation and a pointer to the patch.

Briefly, the patch adds a new option, 'RunScripts' to the Allow directive
of access.conf and .htaccess files; this option designates a directory as
containing both files and scripts.  Scripts in these directories are
identified by a suffix (either '.doit' or '.nph', the latter having the
same effect as the 'nph-' prefix).

These suffixes are added to the incoming URL by the server during the
search for a script, and are therefore *not* present in the URLs which
invoke the scripts.  This means that any file in a 'RunScripts' directory
can be replaced with a script without changing documents which have links
to it.  This is a feature, IMATSHO (that is, In My And Tony Sanders' Humble
Opinions :-), although it does get a little awkward when the file being
replaced already had a type-suffix.

The main problem with any such scheme is security. For all sorts of
reasons, it's a bad idea to let The Outside World (including potential
attackers) read the code of your scripts.  In order to prevent this, at
least around here, it's *not* enough to prevent the server from tossing
files which appear to be scripts over the wall --- script code appears in
emacs backup and auto-save files as well, and so, to be thorough, I wound
up preventing the export of those.  The trouble is that it's hard to tell
when to stop --- scripts may eventually get patched, for instance; do we
ban retrieval of '*.orig'?

What might be safer is to have each directory contain either scripts or
files, but not both --- files could not be retrieved at all from a scripts
directory.  This would also get rid of the suffixes, which some people find
objectionable (even though most Web servers already use dot-suffixes to
determine a file's MIME type).  However, this does represent a real loss in
flexibility for the server maintainer as compared to the suffix hack.

Any comments?