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