Re: CGI/1.1 draft (Rob McCool)
Date: Wed, 16 Mar 1994 07:42:22 --100
Message-id: <>
Precedence: bulk
From: (Rob McCool)
To: Multiple recipients of list <>
Subject: Re: CGI/1.1 draft
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
Content-Length: 2924
 * Re: CGI/1.1 draft  by George Phillips
 *    written on Mar  6, 11:30am.
 * While Accept:, Content-Type: and Content-Length: are literally in
 * the CGI variable space, only a munged version of Authorized: is
 * there.  How about changing that to "does not include Authorized:
 * if server is doing the authentication on that script, otherwise
 * is does."  For a script with simple authorization requirements,
 * the server can do the work.  When the script gateways into something
 * where server authentication is inappropriate or impossible
 * (like an Oracle database), the writer can use an "nph-" script and
 * do the authentication herself.

Hmmm. I don't think that would be a problem for NCSA httpd, what about the
others (John, Tony, Ari)?

Also, what about, instead of making it REQUEST_EXTRA_HEADERS, how about
placing each line in a variable? This way, you would have HTTP_FROM for the
from: line, etc. This makes HTTP_ACCEPT just another header. Any header
lines with - would have the - translated to _. Multiple instances would be
concatenated into the variable with commas as separators. Anyone see a
problem with this?

 * Please, please leave PATH_INFO escaped.  It was a mistake to do the
 * unescaping in the server; let's fix it.  Sure, it's not strictly
 * backwards compatible, but I seriously doubt many scripts relied upon
 * the old behaviour.  Besides "%3d", there's also "%00" which a CGI
 * script really loses on.

I don't agree. I think that with dummy inputs available in forms, we can
finally move away from using PATH_INFO to convey state information to
scripts and go back to using them for their intended purpose: To allow
scripts to access the server's virtual->physical translation and access
authorization for auxillary files. If you're using filenames in PATH_INFO
then you don't have to escape the information, and if you have it as dummy
inputs in a form then your data is already escaped anyway.


Updated proposed changes list:

1. Any headers without special meaning to the server which are output by
non-nph scripts are to be passed back to the client.

1a. A new special header will be added to the script's output. Status: will
convey a 3-digit HTTP status code followed by a reason string. Example:
Status: 403 Forbidden

2. The header lines from the client, if any, are to be placed into the
environment with the prefix HTTP_ and followed by the header name. Any -
characters in the header name should be changed to _ characters. This does
not include Authorization: if the server has already processed the
Authorization: line. 


GET / HTTP/1.0
User-agent: DisintegratorWWW 1.1
Accept: text/html
Accept: text/plain

The CGI env. variables for this transaction's headers would be

HTTP_USER_AGENT="DisintegratorWWW 1.1"
HTTP_ACCEPT="text/html, text/plain"

Comments welcome