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