ID:               36705
 Comment by:       bryan at b1t5 dot com
 Reported By:      alisencer at gmail dot com
 Status:           Open
 Bug Type:         Documentation problem
 Operating System: FreeBSD
 PHP Version:      5.1.2
 New Comment:

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);
            continue;
        }
------------------------------------
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)


Previous Comments:
------------------------------------------------------------------------

[2006-03-13 03:55:42] 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-03-12 19:39:18] 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-12 19:02:26] [EMAIL PROTECTED]

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 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.

------------------------------------------------------------------------

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

Reply via email to