#36705 [Com]: Location header results in duplicate Status header ([f]cgi only)

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] mike@php.net 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] mike@php.net 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