revised CGI/1.0 specification

George Phillips (
19 Nov 93 16:18 -0800

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.

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

Now for a couple of picky naming things of my own:

PROTOCOL_METHOD -- is "REQUEST_METHOD" more meaningful?

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

>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....].

-- George