Re: CGI/1.0: last call (fwd)

Rob McCool ([email protected])
Sat, 4 Dec 1993 20:12:59 -0600


/*
* Re: CGI/1.0: last call (fwd) by John Franks ([email protected])
* 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: http://hoohoo.ncsa.uiuc.edu/cgi/
*
* Server action:
*
* Issues HTTP/1.0 redirect message redirecting to URL
* http://hooh0.ncsa.edu/cgi/
*
* ------------------

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
* > QUERY_STRING.
*
* I assume the query information is everything after the ? in the URL.

Yep.

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

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

Yes.

* 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
* [email protected]
*
*/