ID: 36705
Updated by: [EMAIL PROTECTED]
Reported By: alisencer at gmail dot com
Status: Open
Bug Type: Documentation problem
Operating System: FreeBSD
PHP Version: 5.1.2
New Comment:
I can't find a single evidence that a "Status:" header is treated
differently than any other header in PHP versions 4.3, 4.4 and 5.1 --
and we can't do anything about Apache changing its behaviour.
Why don't you just send the appropriate status header with the header()
call?
header("Location: uri", 1, 301);
Previous Comments:
------------------------------------------------------------------------
[2006-03-12 18:29:38] ali dot sencer at gmail dot com
We had definitive, reproducable bug-reports for our php-application,
where sending HTTP/1.1 ... type status-codes was ignored. In fact, if
you read the comments on this page:
http://de.php.net/manual/en/function.header.php
you will find several people noting that HTTP/1.x doesn't work with
CGI.
In fact here is something reproducable:
- use this in your .htaccess:
ErrorDocument 404 /test.php
- then call an invalid url
- the response code will be 404 (fine). Try setting the Status code
with header("HTTP/1.1 200"); it won't work (it still returns a 404),
but using header("Status: 200"); yields the desired result and returns
a 200. So obviously saying always use HTTP/1.x and never use Status:
doesn't work in reality.
To let you know where we're coming from: At this point we've come full
circle:
1) We used only HTTP/1.x when starting out. Then moved
2) to use both HTTP/1.x and Status: at the same time, then
3) to use HTTP/1.x and Status: depending on sapi_name,
4) and now back to only using HTTP/1.x
always user-complaints would drive the changes, and each time it would
fix it for some and break it for others.
------------------------------------------------------------------------
[2006-03-12 17:22:23] [EMAIL PROTECTED]
It's even that way in PHP-4.
------------------------------------------------------------------------
[2006-03-12 16:29:20] ali dot sencer at gmail dot com
download and tried it (php5.1-200603121330)
$ ./php -v
PHP 5.1.3RC2-dev (cgi-fcgi) (built: Feb 20 2006 15:24:12)
...
[EMAIL PROTECTED]:~/php5.1-200603121330/sapi/cgi$ echo "<?php header( 'Status:
301' );header( 'Location: http://www.example.org' );?>" | ./php
Status: 302
X-Powered-By: PHP/5.1.3RC2-dev
Status: 301
Location: http://www.example.org
Content-type: text/html
The bug is still present.
> One should not use "Status: 123" but "HTTP/1.x 123".
Did I miss an announcement? Since when is that? Using HTTP/1.x type
headers was not working on a variety of systems with (f)cgi, which is
why the following snippet was introduced (which is in a lot of
applications):
if (substr(php_sapi_name(), 0, 3) == 'cgi')
header("Status: $status");
else
header("HTTP/1.1 $status");
(which was the only solution that worked on all systems - until some
recent changes in newer releases.)
I could have sworn this was somehwere in the documentation even. So in
which versions was this changed? How can portable applications in PHP
be written, if these things change silently every now and then.
Why can header("Status: ") be used at all, if it's not supposed to be
used?
Can the behaviour at least be "fixed" in such a way, that (f)cgi won't
send "Status: " twice, which results in a 500 error by the webserver.
Thanks.
[edit: I am the bug-submitter, but must have mistyped my password]
------------------------------------------------------------------------
[2006-03-12 15:55:22] [EMAIL PROTECTED]
Recalssifying as a documentation problem.
One should not use "Status: 123" but "HTTP/1.x 123".
------------------------------------------------------------------------
[2006-03-12 15:39:18] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36705
--
Edit this bug report at http://bugs.php.net/?id=36705&edit=1
