> - Update the PHP header() documentation to mention this. I was also
> thinking that supporting/documenting header(null, true, 404); or the
> like would be nice for people who only want to set the return code and
> leave the HTTP type unchanged.
I think this would bet he best approach, to give the PHP a users a
_consistent_ way (consistent through all SAPIs) to set the http response
code without changing protocols.
Your problem only occurs with apache, as apache gives PHP the possibility to
change the HTTP protocol version. Other SAPIs, like my NSAPI one, cannot do
this because the protocol is the servers task and modules are not allowed to
change it in a wrong way.
The problem with setting the response code is:
* Some PHP scripts use header('Status: 301') to set response code. Problem
here: This only works with CGI and Apache. The problem here is in PHP SAPI
code: PHP only checks for ('HTTP/...') header strings and extracts status
code and protocol version from it. The string 'HTTP/..' is never send to the
SAPI. In case of 'Status: ', SAPI sends the header as a _normal_ HTTP header
to the webserver -> Apache maps this, CGI also because specs want this.
* Some scripts use header('HTTP/1.0 301 Moved Permanently'). Problem here:
You must supply a HTTP version (this seems to be a problem in Apache), and
you must supply the textual representation (but most/all? SAPIs ignore the
textual representation). So header('HTTP/1.0 301 X') would be OK.
What we need is:
1) a consistent parsing of header() inputs before sending to the underlying
SAPI. This means also parsing for 'Status: XXX' and setting the status code.
The later SAPI then will generate the correct parameters to be sent to the
server (in case of CGI it will "regenerate" a Status:-header).
2) a function to simply set the status code without changing anything other.
1. supplies such a method with 'Status: 301' if it is correctly implemented.
If nobody is against it I would try to implement a consistent header parsing
for SAPI...
