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
GET / HTTP/1.0
User-agent: DisintegratorWWW 1.1
The CGI env. variables for this transaction's headers would be