n) There should not be any indication within the URL, selector string,
etc., as to whether or not a retrieval will cause a script to be
invoked.
Unfortunately, as near as I can tell, there is no way to reconcile this
desideratum with John's.
The reason I want it is that having put something up as a file, or
collection of files, I may want to turn it into a script, without having to
track down all the references to it and change them as well --- which I
would necessarily have to do if the script/file distinction were explicit
in the URL (selector, whatever). The 'eyes-only document hack' provides, I
think, one fairly reasonable example of where one might like to do this.
Conversely, I might also want to take something that I've put up as a
script, and replace it with a collection of files --- as in the case of
replacing my on-the-fly info gateway with the output of a batch translator.
I want to be able to do this without having to find and change every
reference to an info node anywhere on my server.
Now, in order to satisfy the goal above, you need some way of
distinguishing the scripts from the ordinary files, other than selector
syntax. In other words, you need a mechanism for typing the files.
Like it or not, most of the existing servers already have such a mechanism
--- to tell what type a file is (in order to report the proper MIME type),
they discriminate on the basis of the name. If you put a GIF file up under
the name 'foo.au', or even just plain 'foo', then (with the stock NCSA
server, and Plexus and CERN as well, I believe), the wrong MIME type will
be reported back to the client, and things fall apart. If you want to get
rid of arbitrary naming conventions, this may be the best place to start.
Scripts could easily piggy-back on any solution to the file-typing problem
--- just type them as application/x-cgi-run-it-here, and make the server
give special treatment to that type (as the NCSA server already does for
text/html with Charles' server includes).
But, supposing the script type is different enough from other types that we
want some completely different mechanism for indicating files of that type.
For instance, we could use the 'x' bit. Now, 'x' bits sometimes do get set
where they aren't meant to be --- typos happen. Generally, this doesn't
matter much. A C source file with an 'x' bit is still a perfectly useful C
source file. However, with this scheme, an 'x' bit on a data file in the
server arena makes it impossible to retrieve the file.
For instance, suppose some novice slips up with chmod, and the 'x' bit gets
set on a form coversheet --- his fingers ran away with him, and instead of
'chmod foo', he typed 'chmod foo*'. Then, when the luser attempts to
retrieve the coversheet, the server sees the 'x' bit on it, and tries to
run it as code. When this fails, the poor guy sees:
500 Server error.
The script '...' failed to produce output...