Identifying scripts by file extension?
nholtz@civeng.carleton.ca (Neal Holtz)
Errors-To: secret@www0.cern.ch
Date: Fri, 11 Feb 1994 08:32:54 --100
Message-id: <9402102119.AA26915@zonker.cascade.carleton.ca>
Errors-To: secret@www0.cern.ch
Reply-To: nholtz@civeng.carleton.ca
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: nholtz@civeng.carleton.ca (Neal Holtz)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Identifying scripts by file extension?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 3283
I think this was beat to death a month or two ago, but ...
Currently, the only accepted way to designate a script gateway in a
URL is to use some magic prefix such as "/cgi-bin/myscript/" to the
the path. Unfortunately, this co-exists very poorly with the rules
for forming full URL's from relative ones (see below). What is the
general opinion on using the file extension to identify gateways or
scripts?
I have a small patch to NCSA HTTPD 1.1 which allows srm.conf entries
like:
ScriptExtension .xyz ZZZ
Then, path names that end in ".xyz" will be handled as though they
had "ZZZ" prepended, provided:
a) the path hasn't been aliased, and
b) the path doesn't already start with a script alias, and
c) The path, after prepending "ZZZ", starts with a script alias.
Therefore, with an entry like
ScriptExtension .qml /htbin/tutorial
a path like
/~nholtz/91.111/q1.qml
would be handled as though it were
/htbin/tutorial/~nholtz/91.111/q1.qml
Anybody else think this is desireable?
--------------------------
BACKGOUND (long) (for those who aren't convinced)
I am starting to develop a large document (set of lecture notes +
study guide) that has quite a mixture of node types. Many of the
HTML files require some filtering before being delivered to the
client: one gateway filter handles delivery of tutorial style
questions and the responses to them; another is sort of an "outline
processor" that reveals more of the text, in line, when certain links
are selected.
The basic problem is in the relative URL's that I would like to use.
Having the script identifier at the front of the path name means that
I have to use absolute URL's a lot, and that is going to be a real
pain in a few weeks when I want to move things around. Identifying
the script in the last component of a path means that I can use
relative URL's everywhere, which makes life a lot easier.
That script identifier is a type specification of a node (actually,
it is both a type specification and instructions on how to convert
the type of the node into one of the standard types). It has been
decided, long ago, that type information will not be carried by the
underlying file system. It also seems to be undesireable to have the
file contents themselves reveal the type information. Therefore that
type specification has to be part of the name (URL).
If the type information is encoded in the front portions of path
names, and if the rules for generating full URL's from relative ones
call for replacement of the rear portions of the path name, then it
is impossible to use a relative URL to link to a node of a different
type (because the replacement rules wouldn't allow replacement of the
type information).
But of course, the rear portion (extension) is already used to convey
some type information (".gif" for certain types of images, etc). It
is only gateway scripts that are currently forbidden to use this
mechanism.
What I am proposing is simply to allow the identification of scripts
to be consistant with the identification of other types of data - to
be able to use the file extension as that mechanism.
---
Prof. Neal Holtz, Dept. of Civil Eng., Carleton University, Ottawa, Canada
Internet: nholtz@civeng.carleton.ca Ph: (613)788-2600x5797 Fax: (613)788-3951