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?
> Guy Decoux writes:
> 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"
>
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.
John Franks Dept of Math. Northwestern University
john@math.nwu.edu