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]
*
*/