Re: ncsa httpd 1.0a2 BinAlias option

• Mail folder: WWW Talk Jul-Oct 1993
• Next message: Tim Stockwell: "Backing out of an html multi-file document"
• Previous message: ira@linus.mitre.org: "Crawling info displays and slide shows "

Date: Thu, 30 Sep 1993 16:14:02 -0400
From: Jim Davis <davis@dri.cornell.edu>
Message-id: <199309302014.AA21206@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: ncsa httpd 1.0a2 BinAlias option

> From: kevin@scic.intel.com (Kevin Altis)
> Subject: ncsa httpd 1.0a2 BinAlias option
 
> ...  a standard name that all
> servers will support (if possible) and that users can expect to use.

While I agree that it will often be useful to run a script
on the server to generate a document, and agree that NCSA's
httpd is excellent (blessing upon the developers, our
benefactors!) for providing this feature, I think it is 
a mistake to try to make this visible to the user.

I don't think we should support the metaphor of "executing a 
command" on the server.  The metaphor should simply be 
fetching documents via URL.  It may be that sometimes the
server runs a command to generate the document instead
of retrieving it - this should be invisible to the user.
It may be that some URLs will point to scripts, conveniently
loaded by NCSA httpd.  But these should always be hidden.

Our prototypical user is not a Unix hacker who wants the
equivalent of an "rsh".  

What's more, while there is certainly a need to provide scripts
which may only be run when client is "local" to the server,
it's useless to reflect this in the name.  Well, it's not
totally useless, it does tell people "don't expect this to
work unless you are local", which may be useful.  It may also
serve to remind people of potential security holes.  But
if we *did* want to support the notion of remote execution, we
would not want local people to have to remember which commands
are local and which aren't.  we would want the system to
take care of that, in the same way that the shells PATH variable
does.  Another argument to the same effect - there might easily
need to be more than two levels of security - e.g. some "commands"
are only for financial people, others for personnel, still
others for the medical people, and so on.

Finally, we wouldn't want a new protocol type (exec: and
exec-local:) since the protocol is not the least bit different.

best wishes to all