ID: 36705 Comment by: phpbugs at thequod dot de Reported By: alisencer at gmail dot com Status: Open Bug Type: Documentation problem Operating System: FreeBSD PHP Version: 5.1.2 New Comment:
As far as I remember from looking around because of the already mentioned "bogus" bug http://bugs.php.net/bug.php?id=33225: The CGI spec says that there should only be one Status header. 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. Previous Comments: ------------------------------------------------------------------------ [2006-04-22 07:57:34] 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); 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) ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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
