Re: ncsa httpd 1.0a2 BinAlias option

• Mail folder: WWW Talk Jul-Oct 1993
• Previous message: Tony Sanders: "Re: virtual documents and <BASE> "

Message-id: <9309302244.AA05910@void.ncsa.uiuc.edu>
From: robm@ncsa.uiuc.edu (Rob McCool)
Date: Thu, 30 Sep 1993 17:44:13 -0500
In-Reply-To: Jim Davis <davis@dri.cornell.edu>
       "Re: ncsa httpd 1.0a2 BinAlias option" (Sep 30,  4:14pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Jim Davis <davis@dri.cornell.edu>, www-talk@nxoc01.cern.ch
Subject: Re: ncsa httpd 1.0a2 BinAlias option

/*
 * Re: ncsa httpd 1.0a2 BinAlias option  by Jim Davis (davis@dri.cornell.edu)
 *    written on Sep 30,  4:14pm.
 *
<stuff deleted>
 * 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".  

This is how I envision it as well, in that the server has its own namespace
  and can do whatever it likes with the URL it recieves.

 * 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.

I agree, these are all issues that should be transparent to the referencing 
  document. Whether a document requires user authentication, or hostname 
  authorization, the document should not have to worry about these issues.

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

I agree here, too, the metaphor of a filespace is adequate and flexible.

--Rob