Re: CGI stuff

George Phillips <phillips@cs.ubc.ca>
Errors-To: listmaster@www0.cern.ch
Date: Tue, 1 Mar 1994 08:48:16 --100
Message-id: <7620*phillips@cs.ubc.ca>
Errors-To: listmaster@www0.cern.ch
Reply-To: phillips@cs.ubc.ca
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: George Phillips <phillips@cs.ubc.ca>
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: 2791

Rob said:
>I say nay on an initial proposal of a npa- script that gets the headers on
>stdin, exactly as the client sent them. I also think that the initial line
>(GET /blah HTTP/1.0) can already be reconstructed from information the
>script has (that is, in a server that doesn't un-escape PATH_INFO) and isn't
>necessary. The same goes for SERVER_ADDRESS, it should at the very least be
>SERVER_URL or SERVER_URL_PREFIX and I don't see why it is necessary, since
>we may be abstracting the URL representation for the protocol but we already
>know the protocol: HTTP. If you're not using HTTP, then REQUEST_PROTOCOL
>should not say HTTP.

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.

>What I would consider is a new env. variable called REQUEST_EXTRA_HEADERS
>which would contain the text of all the headers the server didn't
>understand. I don't support giving all of them to the script (notably
>Authorization) since in the case of authorization, I don't want every script
>to have the users' passwords in near-plaintext. I also don't support it
>because then we'd have two copies of Mosaic's 700 byte accept headers and
>on some systems, we're that much closer to the dreaded ARG_MAX.

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?
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-".