Re: CGI/1.1 draft
robm@ncsa.uiuc.edu (Rob McCool)
Errors-To: listmaster@www0.cern.ch
Date: Wed, 16 Mar 1994 07:42:22 --100
Message-id: <9403160638.AA08424@void.ncsa.uiuc.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: robm@ncsa.uiuc.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: robm@ncsa.uiuc.edu (Rob McCool)
To: Multiple recipients of list <www-talk@www0.cern.ch>
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.
Example:
Client:
GET / HTTP/1.0
From: marvin@mars.gov
User-agent: DisintegratorWWW 1.1
Accept: text/html
Accept: text/plain
The CGI env. variables for this transaction's headers would be
HTTP_FROM="marvin@mars.gov"
HTTP_USER_AGENT="DisintegratorWWW 1.1"
HTTP_ACCEPT="text/html, text/plain"
Comments welcome
--Rob