(Rob McCool)
Message-id: <>
From: (Rob McCool)
Date: Thu, 30 Dec 1993 12:51:49 -0600
In-Reply-To: (John Franks)
       "" (Dec 28,  5:30pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: (John Franks), (Robert S. Thau)
Content-Length: 3801
 *   by John Franks (
 *    written on Dec 28,  5:30pm.
 * According to Robert S. Thau:
 * >
 * > First off --- CGI/1.0 already has a naming convention which some people
 * > find at least irksome, the 'nph-' business.   
 * I too find it irksome.  Not horrible, but irksome.

At the time, it was either that or a config file directive. Eventually we
opted for the nph- syntax as the lesser of two evils. If anyone has any
cleaner suggestions I'm listening.

 * > Secondly --- if scripts and
 * > ordinary files coexist in the same directories, and the server can't tell
 * > them apart by the names, then how *can* it tell them apart?  How is the
 * > server to know whether to read the file or to run it?
 * > 
 * Using Charles Henrich's suggested syntax, for example, URLs like
 * 	http://host/path/script;
 * 	http://host/path/script;foo
 * 	http://host/path/script;foo?bar
 * would all be scripts.  I.e. the presence of the ';' indicates it is
 * executable.  An trailing ';' just indicates an empty PATH_INFO.
 * > 
 * > > Adding unnecessary complexity to the
 * > > server is undesirable.  You have now added more code to your server
 * > > and you still don't have the functionality (much less the simplicity)
 * > > that a very minor change in the protocol would give.
 * > 
 * > I'm not sure what you're getting at.  What functionality don't I have?
 * > Please be specific --- show me something I can't do.  
 * OK, it is not a big deal, but I do think the current syntax has less
 * functionality and is less flexible than the one described above. If I
 * understand you correctly with your server you can't have a script with
 * an arbitrary path and an arbitrary name.  You must either have a magic
 * directory name like "cgi-bin" in the path above the script or the
 * script must have a name ending in a special suffix like ".doit".  On
 * my server, I have scripts which are both executed and served as text
 * documents.  Which of these is done depends on how the URL references
 * them.  In the syntax described above, for example, the script would be
 * executed if the URL ends with ';' and treated as a document
 * otherwise.  I know you can do the same thing by making a symbolic link
 * to your script with a doit-less name, but this is, as you put it,
 * just "one more inessential detail to keep track of".

Well, requiring a ; in script names isn't that bad, but again, it breaks
everything that's already out there and I'm really hesitant to do that. 

 * Now, could you explain, how the ';' mechanism is more complex than the
 * current syntax?  I find it hard to see how writing a script which
 * outputs
 * 	http://host/path/script;info
 * is more complicated than one which outputs
 * 	http://host/path/script/info
 * The value of the environmental variable PATH_INFO would be the same
 * with either syntax, so that couldn't make any difference.

Personally, I don't see any added complexity, however, we have to keep the
installed script base in mind. I sure as hell don't want to go into all of
my script-using HTML docs and add a ; to the end of every script HREF.

 * Also could you explain why you find the ';' mechanism less flexible
 * than the current syntax.  I think the example above shows that the ;
 * mechanism is *more* flexible than the current one.  Since it would be
 * trivial to translate the ';' to a '/', I think it is clear that
 * Charles' suggested syntax contains at least as much information as the
 * current syntax and hence is at least as flexible.

Yes, I agree, it is a syntactical change that should have been included a
month ago, since it avoids a lot of stat()'s and apparently some confusion,
but to me it seems that we should keep what we already have.