Re: revised CGI/1.0 specification

Rob McCool (
Sun, 21 Nov 1993 19:12:50 -0600

* revised CGI/1.0 specification by George Phillips (
* written on Nov 19, 4:18pm.
* Rob sez:
* >The problem is that I'd like scripts to have the flexibility of returning
* >the header if they so choose, without the server deciding for them.
* Well, my concern was purely an efficiency one, but it's not the
* header parsing that's the problem. It's the copying of the
* rest of the data that I wish to avoid. If the script and the
* server agree ahead of time, the script can be forked with its
* output directed straight at the network rather than having to
* go through the server. You can decide for yourself if that
* copying overhead is worth avoiding. I would expect the
* server and the script to have some extra-interface agreement
* on the output format -- the server would never unilaterally
* demand that the script do HTTP/1.0 output unless configuration
* information said the script wanted it.

Hmmm, I see what you mean. Yes, the copying overhead is definitely worth
avoiding. I can't really think of a good way to configure whether a script
will want to have the header parsed or not...

* Anyhow, I think the change to "Gateway-protocol:" is a good one.
* >Sending the whole header to the script.
* If you feel it's too complex to send the header, then let's not do
* that. I think you're right, the script will rarely care about
* anything but "Accept:". How about we add another environment
* variable for "Accept:" fields and leave room for more fields as
* that becomes necessary. Call it "HDR_ACCEPT", and it will contain
* ";" separated concatenations of the Accept: headers (I think ";"
* separated is within the MIME way of things). Future header fields
* will use the variables "HDR_fieldname".
* Or, we could just dump the whole header into "HEADER".

I'd rather just have an env. variable like "HTTP_ACCEPT" with what you
describe above.

* Now for a couple of picky naming things of my own:
* PROTOCOL_METHOD -- is "REQUEST_METHOD" more meaningful?

Both good points.

* And a few minor points:
* >QUERY_STRING: That which follows the ?, untouched
* Will not be in the environment if original URL has no "?"


* >argv[2....] is the decoded query info, split on pluses or ampersands.
* And should not appear if there is no query. But this conflicts
* with:
* >If the resulting string is too lengthy to place on the command line,
* >the server will not provide argv[2.....] at all and the script must
* >either report an error to the client or decode the URL itself.
* Well, if QUERY_STRING is only optionally in the environment, it
* doesn't matter what happens with argv[2....].

With QUERY_STRING specified, if argv[2...] is unset then the script knows it
was too long to translate.