Re: CGI stuff

• Mail folder: WWW Talk Jan 94-present
• Next message: Roy T. Fielding: "Re: Questions about HTML conventions "
• Previous message: George Phillips: "Re: CGI/1.1 draft"
• Maybe in reply to: John Franks: "Re: CGI stuff"

Errors-To: listmaster@www0.cern.ch
Date: Sun, 6 Mar 1994 20:55:15 --100
Message-id: <7687*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: 1813

Rob said:
>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.

Well, it's a semi-foward looking thing.  Right now, we only have
HTTP commonly using CGI.  I also have my x-exec: browser extension
which probably isn't in use on a large scale.  If other access
protocols get used, PROTOCOL_URL_PREFIX will be a big win in using
those dusty CGI scripts.  Should you add the variable, I'd recommend
having it include the nearly redundant host:port info since there's
no guarantee that $PROTOCOL_URL_PREFIX$SERVER_HOST:$SERVER_PORT is
the right thing to say.

>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?)

I see CGI in two ways.  First, as an abstract environment where
programs can take URLs and spit out MIME objects.  I think this
is a good thing to have.  Second, CGI is to HTTP as inetd is to TCP/IP.
It is also useful as a vehicle to do everything an HTTP server
can do without having to write your own server.  Dropping in
CGI scripts that do things your server can't do is what CGI
is all about.  Why make any limitations on those capabilites by
not passing all or the headers or insisting that some of them
be server-only like Authorization:?

Maybe you don't agree, but I think that at least explains my
apparently contradictory suggestions.  Anyhow, if all the rest of
the headers are in REQUEST_EXTRA_HEADERS, that's as good as "npa-"
and is fine by me.