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.