Re: CGI stuff

robm@ncsa.uiuc.edu (Rob McCool)
Errors-To: listmaster@www0.cern.ch
Date: Tue, 1 Mar 1994 09:25:32 --100
Message-id: <9403010822.AA14970@void.ncsa.uiuc.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: robm@ncsa.uiuc.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: robm@ncsa.uiuc.edu (Rob McCool)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: CGI stuff
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 3273

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