Re: CGI suggestion (Rob McCool)
Message-id: <>
From: (Rob McCool)
Date: Thu, 30 Dec 1993 11:59:37 -0600
In-Reply-To: (John Franks)
       "Re: CGI suggestion" (Dec 28,  9:46am)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: (John Franks), (ts)
Subject: Re: CGI suggestion
Content-Length: 2598
 * Re: CGI suggestion  by John Franks (
 *    written on Dec 28,  9:46am.
 * > Marc Andreessen writes:
 * > > Who is "I" in this context?  If I == the server, then the server's
 * > > file hierarchy is in fact known.  If I == some user, then it doesn't
 * > > matter one way or the other, does it (since the URL should be
 * > > considered opaque anyway)?  I'm probably missing something...
 * > 
 * Well the "I" might be a server maintainer who is not fully cognizant
 * of the details of CGI, and would expect something which looks like
 * a path to a file to be one.  Such a maintainer may not, in the best
 * of all possible worlds, really *need* to know what is going on, but
 * that won't prevent mail to the developers saying "File /cgi-bin/foo1/foo2
 * is not in the distribution I got; where is it?"
 * Also is it really clear that no future caching mechanism will ever
 * need to parse the URL?

I would hope so, since the contents after the third slash are very

 * >  Actually you can't have a subdirectory under "/cgi-bin". Example :
 * > 
 * >  http://server/cgi-bin/subdir/script/extra_path
 * > 
 * >  With this URL server, actually, call "subdir" and not "subdir/script"

I don't understand where this impression is coming from. /cgi-bin is in no
way special, and you can in fact have multiple subdirectories under a
ScriptAlias directory (I just tried it).

 * This is something that was not clear to me from reading the spec.  I
 * did not realize that the name "cgi-bin" was in any way special. Is,
 * in fact, "cgi-bin" going to be a reserved word in http URL's?  If so
 * then my objection about parsing is not well founded.  This is easy
 * enough to parse -- it will still confuse some people though.  It also
 * seems like a rather artificial restriction.  Am I correct in my
 * understanding that this means that any subdirectory of cgi-bin is
 * inaccessible to a client querying the server?
 * Could we clarify the CGI spec some more?
 * 1. Is "cgi-bin" a reserved directory name?

 * 2. Can it be anyplace in the directory hierarchy?

 * 3. Can a server have more than one cgi-bin?


 * and most importantly
 * 4. Is it the case that in any URL containing "cgi-bin" everything
 *    from the second '/' after "cgi-bin" to the end of the URL is always
 *    path info, optionally followed by a ? and a query string?


 * If the answers to questions 1-4 are all "yes", then I will withdraw my 
 * suggestions. I still think this is a less than optimal syntax, but it
 * is usable.