Re: CGI stuff

Rob McCool (robm@ncsa.uiuc.edu)
Tue, 1 Mar 1994 09:25:32 --100

/*
* Re: CGI stuff by George Phillips
* written on Mar 1, 8:49am.
*
* The nice part about CGI is that most scripts don't have to care about
* SERVER_PROTOCOL (unless they need POST information, are nph- scripts
* or wish to output self-referencing URLs). This is a good thing. CGI
* could be used with an entirely differnent access protocol like gopher:
* or x-exec:. With proper use of SERVER_URL_PREFIX, most of your CGI
* script could be dropped right into this new server without modification.
* Otherwise, you'll end up with code like:
*
* if ($rp eq 'HTTP/1.0' || $rp eq 'HTTP/1.0') print "http://$srv:$port/";
* if ($rp eq 'gopher') print "gopher://$srv:$port";
* if ($rp eq 'x-exec') print "x-exec://$srv";
*
* instead of:
*
* print $SERVER_URL_PREFIX;
*
* and even then the mapping of current CGI variables onto the different
* protocol schemes may not be entirely appropriate. All in all I'd say
* that CGI should have had SERVER_URL_PREFIX instead of SERVER_NAME
* and SERVER_PORT from the beginning since the former is much more suited
* to self-referencing URLs.

Hmmm, the problem I was considering was that I believed gopher could not
support arbitrary types returned by a script. From what I just read of the
GN documentation, it seems that GN supports it. In the interests of script
simplicity perhaps we should make a variable such as PROTOCOL_URL_PREFIX
which contains http:// or gopher:// etc.

* I don't understand what you mean by 2 copies. Wouldn't the Accept: headers
* live in HTTP_ACCEPT and not be duplicated in REQUEST_EXTRA_HEADERS?

What I mean is that I don't support placing ALL of the headers in a
variable, I would support only putting the unknown ones there. Sorry that
wasn't clear.

* At any rate, I think this argues in favour of "npa-". No worries about
* environment variable space or what should or should not be passed to
* the script while giving CGI/1.1 writers the power to do anything. I
* agree that passing the first line is not necessary, just the headers
* on down.
*
* Did you have any particular reason why you don't want "npa-"? Seems like
* it would fall out of the NCSA httpd code quite nicely if you don't pass
* the first "method url" line. I certainly think script writes would
* like to see "npa-".
*/

Actually, currently it doesn't if you consider user authentication,
especially PGP/PEM. I don't know how it fits into the other servers.

It's curious that you would like to see protocol independence (in URL
returns), but want to introduce a completely HTTP-dependent feature into
CGI/1.1. How does npa- fit into gopher CGI execution? (John?)

My main problem is that I feel that this doesn't fit well into CGI, and
would better fit into a different protocol for actual server modules
instead. One of the things I'm working on for httpd 2.0 is extensive
modularity: a well documented API as well as an external interface for
installing custom methods for doing access control, virtual->physical
translation, etc. This is where I believe such functionality belongs, since
it is cleaner (both documents and scripts could have custom access control),
at it doesn't further pollute an already HTTP-biased specification.

Comments? John, Ari, Tony?
--Rob