|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #36705 Location header results in duplicate Status header ([f]cgi only)
Submitted: 2006-03-12 14:14 UTC Modified: 2008-04-13 23:36 UTC
Avg. Score:4.4 ± 1.0
Reproduced:21 of 23 (91.3%)
Same Version:6 (28.6%)
Same OS:4 (19.0%)
From: alisencer at gmail dot com Assigned:
Status: Closed Package: Unknown/Other Function
PHP Version: 5.1.2 OS: FreeBSD
Private report: No CVE-ID: None
 [2006-03-12 14:14 UTC] alisencer at gmail dot com
In php-fastcgi, a header("Location: ..") call always results in an additional "Status:" header.  This causes the web server to throw a 500 Internal server error.

Identical code works perfectly in mod_php.  The problem is specific to fastcgi.

It doesn't matter what Status code the first header() call sends; the "Location:" call always adds a second "Status: 302" line.

The effect is, that it becomes impossible to use header("Location;..."), if at any previous point in the script a Status header has been sent. It is also contrary to what the documentation says:

"The second special case is the "Location:" header. Not only does it send this header back to the browser, but it also returns a REDIRECT (302) status code to the browser unless some 3xx status code has already been set." 

(Note the last part of that paragraph)

Related: This seems to be what was happening in this bug report as well: which unfortunately was closed as bogus.

Reproduce code:
$ echo "<?php header( 'Status: 301' );header( 'Location:' );?>" | php/php-fastcgi/php5-fcgi 

Expected result:
Content-type: text/html; charset=UTF-8
Status: 301

Actual result:
Status: 302
Content-type: text/html; charset=UTF-8
Status: 301


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2006-03-12 15:39 UTC]
Please try using this CVS snapshot:
For Windows:

 [2006-03-12 15:55 UTC]
Recalssifying as a documentation problem.

One should not use "Status: 123" but "HTTP/1.x 123".

 [2006-03-12 16:29 UTC] 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)

sencer@dev:~/php5.1-200603121330/sapi/cgi$ echo "<?php header( 'Status: 301' );header( 'Location:' );?>" | ./php

Status: 302
X-Powered-By: PHP/5.1.3RC2-dev
Status: 301
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");
	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 17:22 UTC]
It's even that way in PHP-4.
 [2006-03-12 18:29 UTC] 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:

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 19:02 UTC]
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);

 [2006-03-12 19:39 UTC] ali dot sencer at gmail dot com
> and we can't do anything about Apache changing its behaviour.

I hadn't considered that, sorry. And thank you for taking the time. 

> Why don't you just send the appropriate status header with
> the header() call?

The issue is, we send a Status: 200 very early to override the 404 (from the error-handler). After that the code branches in many different ways, and plugins and extensions sometimes make changes to (i.e. replace) the Status-code as well. Given that in some situations we need to use a Location-header, we now have to make sure that nobody has ever used "Status: " before. 
So, yeah we can workaround this, but the situation as it is, is everything but intuitive. I guess we'll have to make do....
 [2006-03-13 03:55 UTC] judas dot iscariote at gmail dot com
as an effective workaround to this problem, you can use PEAR HTTP_Header class. 

hint : method sendStatusCode()
 [2006-04-22 07:57 UTC] bryan at b1t5 dot com
The most effective workaround is to just edit mod_fastcgi.c
if (strcasecmp(name, "Status") == 0) {
            int statusValue = strtol(value, NULL, 10);

            if (hasStatus) {
                /* comment out the braindead line below */
                /* goto DuplicateNotAllowed;            */
            if (statusValue < 0) {
                fr->parseHeader = SCAN_CGI_BAD_HEADER;
                return ap_psprintf(r->pool, "invalid Status '%s'", value);
            hasStatus = TRUE;
            r->status = statusValue;
            r->status_line = ap_pstrdup(r->pool, value);
apache doesn't care how many times you set r->status. Set it once, twice, 500 times even -- it doesn't matter cuz r is just a struct you fill up before calling ap_send_http_header(r)
 [2006-05-03 18:37 UTC] phpbugs at thequod dot de
As far as I remember from looking around because of the 
already mentioned "bogus" bug

The CGI spec says that there should only be one Status 

In my humble opinion, PHP should take care of sending only 
one status header.

In the case of "Location:" any existing one should get 
overwritten and not added.
 [2006-12-07 20:21 UTC] chris at vault5 dot com
This bug is filed against FreeBSD but it is certainly not limited to that OS.

Using the Microsoft IIS FastCGI ISAPI extension this issue occurs on IIS, too.
 [2008-04-13 23:36 UTC]
bjori@lindsay:~$ ./php/5.3/sapi/cgi/php-cgi 
header("Status: 301");
X-Powered-By: PHP/5.3.0-dev
Status: 301
Content-type: text/html; charset=utf-8

Works fine now...
 [2010-06-24 11:39 UTC] hanskrentel at yahoo dot de
This was reported to work for 5.3.0 I was curious how that behaves on 5.2.x and did run a test. It works, here are the details:

PHP 5.2.6 (cgi-fcgi) (built: May  2 2008 18:02:06)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
    with Xdebug v2.0.0RC4-dev, Copyright (c) 2002, 2003, 2004, 2005, 2006, 2007, by Derick Rethans

Status: 301
Content-type: text/html
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sat Dec 04 19:03:35 2021 UTC