Re: CGI/1.1 draft

robm@ncsa.uiuc.edu (Rob McCool)
Errors-To: listmaster@www0.cern.ch
Date: Tue, 1 Mar 1994 11:32:35 --100
Message-id: <9403011029.AA16135@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
Content-Length: 2267


I wrote:

/*
 * CGI/1.1 draft  by Rob McCool
 *    written on Mar  1,  2:39am.
 *
 * 
 * Here are my proposals for changes to CGI, to make its version 1.1:
 * 
 * 1. Any headers output by non-nph scripts which the server doesn't understand
 *    may be passed to the client.
 * 
 * 2. Add a new env. variable called HTTP_EXTRA_HEADERS which contains all
 *    headers sent by the client which the server didn't understand. This does
 *    not include Authorized, Accept, Content-type, or Content-length as these
 *    are already elsewhere in the CGI variable space. The server may perform
 *    collapsing of these lines, i.e. it may consolidate multiple occurrences
 *    of these lines as it already does with HTTP_ACCEPT.

To clarify, this is the headers sent by the client which _CGI_ didn't
understand, not what the server didn't understand. Currently, this means
everything except Authorization, Accept, Content-type and Content-length.

 * ---
 * Discussion:
 * 
 * 1: This is has already been discussed and largely agreed upon as a Good
 *    Idea. It's backward compatible with CGI/1.0 behavior, and fits nicely in.
 * 
 * 2: This will allow stupid pet tricks like using From:, but more importantly,
 *    allows us to not need to update the CGI spec every time a new header is
 *    introduced.
 * 
 * Finally, note that I don't mention whether PATH_INFO should be unescaped or
 * not. My first impression is that it should remain escaped, in order to avoid
 * ambiguities like the decoding of foo="1%3d2". Problem is, all of the current
 * implementations are ``broken'', and therefore such a change technically
 * isn't backward compatible. So perhaps we should update the spec. to reflect
 * the implementations. Comments?
 */

To clarify on this point, I just went back and looked at the spec. again.
The current implementations are in fact up to spec., as the specification
has always read that PATH_INFO should be unescaped (dating back to Dec. 13
last year). The notable exception is NCSA httpd 1.x which mistakenly
converts + signs to spaces in file names.

The question is then whether we should have PATH_INFO in fact be escaped, or
unescaped. At any rate, changing this aspect of the specification will break
things, so I'm leery of it.

--Rob