Re: CGI/1.0: last call (fwd) (Rob McCool)
Message-id: <>
From: (Rob McCool)
Date: Sat, 4 Dec 1993 20:12:59 -0600
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
Subject: Re: CGI/1.0: last call (fwd)
 * Re: CGI/1.0: last call (fwd)  by John Franks (
 *    written on Dec  4, 10:09am.
 * Generally very good.  I have no problems with the spec.  I also would
 * like to see the examples Ari mentions.  In fact it would be nice if
 * there were simple minded examples of almost everything.  Not example
 * scripts, but something along the lines of
 * ------------------
 * Script writes to stdout:
 * 	Location:
 * Server action:
 * 	Issues HTTP/1.0 redirect message redirecting to URL
 * ------------------

I'll add examples to everything to make things clearer.

 * Also I find the following passage somewhat unclear:
 * > The command line is only used in the case of an ISINDEX query. It is
 * > not used in the case of an HTML form or any as yet undefined query
 * > type. The server should search the query information for a non-encoded
 * > + character to determine if the command line is to be used.
 * > If the server finds one, it will decode the query information by first
 * > splitting it on the pluses given in the URL. It will then perform the
 * > additional decoding before placing the resulting words on
 * > argv[1....].
 * > If the server finds that it cannot send the string due to internal
 * > limitations (such as exec() or /bin/sh command line restrictions) the
 * > server should include NO command line information and provide the
 * > non-decoded query information in the environment variable
 * I assume the query information is everything after the ? in the URL.


 * Will the client always put a + in this string?  What if it is a single
 * word search term?  I guess I don't understand how the + works to
 * determine whether or not to use the command line.  What does the
 * server do if there is no + so it shouldn't the commannd line?
 * (presumably it does the same thing it does when command line
 * retstrictions prevent it from using the command line.)  Examples here
 * would help a lot.  Probably I don't understand this because I haven't
 * been paying attention, but of course new people will need to read this
 * document without the benefit of the discussion in its creation.

Hmmm. This is a problem. I hadn't thought of that. To answer your question,
a plus would only appear in an isindex query, since we are trusting the
client to % encode spaces in form requests. However, I had forgotten that
not all ISINDEX queries will have a + in them. 

Perhaps instead of using a + to test if a given request is an isindex
request, perhaps we should use whether there is an = in the request to
detect if it's a form request and only decode if it's not a form request.

The problem with that is that it leaves room for error in future
endeavors... what if the next FORMS+ interface doesn't have = in it? The
server shouldn't decode the string but it will if it doesn't find an =

 * Should the server always put the query information in the variable 
 * QUERY_STRING, even when using the command line?


 * I have no quibble, but is there a rationale for decoding for the
 * command line and not for the QUERY_STRING?  Also a reference to what
 * it means to decode the query information, i.e. say it means the
 * standard URL decoding and give a reference for that.

Some scripts will want the query information untouched, which is what
QUERY_STRING is for. Decoding the command line for ISINDEX scripts is to
reduce the load on small script writers.

 * A final nit. I would find it easier to read (and print) if it were a
 * single html doc with internal links rather than several html docs with
 * hyperlinks.
 * John Franks 	Dept of Math. Northwestern University