Re: revised CGI/1.0 specification

robm@ncsa.uiuc.edu (Rob McCool)
Message-id: <9311220112.AA10804@void.ncsa.uiuc.edu>
From: robm@ncsa.uiuc.edu (Rob McCool)
Date: Sun, 21 Nov 1993 19:12:50 -0600
In-Reply-To: George Phillips <phillips@cs.ubc.ca>
       "revised CGI/1.0 specification" (Nov 19,  4:18pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: George Phillips <phillips@cs.ubc.ca>, www-talk@nxoc01.cern.ch
Subject: Re: revised CGI/1.0 specification

/*
 * revised CGI/1.0 specification  by George Phillips (phillips@cs.ubc.ca)
 *    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:
 * 
 * GATEWAY_PROTOCOL -- should be GATEWAY_INTERFACE now
 * 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 "?"

Clarified.

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

--Rob