Bug->Req #47605 [Opn->Wfx]: CGI SAPI can not send HTTP 200 header

Edit report at https://bugs.php.net/bug.php?id=47605&edit=1 ID: 47605 Updated by: cmb@php.net Reported by: c dot c dot dean at durham dot ac dot uk Summary: CGI SAPI can not send HTTP 200 header -Status: Open +Status: Wont fix -Type: Bug +Type: Feature/Change Request Package: CGI/CLI related Operating System: * PHP Version: 5.*, 6CVS (2009-04-25) -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: That's not exactly a bug, but rather a feature request. | In my view, this should be the default behaviour, but if you | think that breaks backward compatibility, could you instead | implement it by allowing cgi.nph = 2 to trigger it? Since cgi.nph is a boolean setting, that would also break BC. Given that there has been no activity on this ticket for more than ten years, I'm closing this is as won't fix. If anybody feels that this feature should be implemented, please pursue the RFC process[1]. [1] <https://wiki.php.net/rfc/howto> Previous Comments: ------------------------------------------------------------------------ [2009-05-06 08:15:44] c dot c dot dean at durham dot ac dot uk Yes, if you use "Status: 200 OK", it does work, so I guess that's a workaround, but it's not very intuitive for this to behave differently to "HTTP/1.0 200 OK". Thanks, Colin ------------------------------------------------------------------------ [2009-05-05 18:45:03] lbarnaud@php.net Does it works with a "Status: 200 OK" header instead of "HTTP/1.0 200 OK" ? ------------------------------------------------------------------------ [2009-04-27 09:52:56] c dot c dot dean at durham dot ac dot uk With cgi.nph = 0, no status header is output unless you invoke header(), and then only if your status code isn't 200. With cgi.nph = 1, a status header is always output, defaulting to 200 if header() is not invoked. What I'd like, and other people have requested, is a situation where a status header is output if and only if you invoke header(), and without any special case for 200. In my view, this should be the default behaviour, but if you think that breaks backward compatibility, could you instead implement it by allowing cgi.nph = 2 to trigger it? Thanks, Colin ------------------------------------------------------------------------ [2009-04-25 16:00:05] jani@php.net What have you set cgi.nph to? Try disabling it first. (See also bug #27026 as this fix changed the behaviour) ------------------------------------------------------------------------ [2009-03-09 14:45:38] c dot c dot dean at durham dot ac dot uk Description: ------------ If you invoke header("HTTP/1.0 200 OK"); from PHP in CGI mode, the header is never output, because it's suppressed at line 379 in sapi/cgi/cgi_main.c. If you use any value other than 200, it is output correctly. This means for instance, that if you use PHP in CGI mode as an Apache errordocument handler, you cannot send back a non-error 200 OK to the user. The following trivial change fixes this, but you might prefer a more elegant solution. --- php-5.2.9/sapi/cgi/cgi_main.c.orig 2009-01-19 18:17:59.000000000 +0000 +++ php-5.2.9/sapi/cgi/cgi_main.c 2009-03-09 14:04:11.000000000 +0000 @@ -376,7 +376,7 @@ return SAPI_HEADER_SENT_SUCCESSFULLY; } - if (CGIG(nph) || SG(sapi_headers).http_response_code != 200) + if (CGIG(nph) || SG(sapi_headers).http_response_code != 666) { int len; zend_bool has_status = 0; @@ -914,7 +914,7 @@ SG(request_info).request_uri = NULL; SG(request_info).content_type = NULL; SG(request_info).content_length = 0; - SG(sapi_headers).http_response_code = 200; + SG(sapi_headers).http_response_code = 666; /* script_path_translated being set is a good indication that we are running in a cgi environment, since it is always Reproduce code: --------------- Use this as the Apache errordocument handler: <?php header("HTTP/1.0 200 OK"); echo "This is OK"; ?> Expected result: ---------------- HTTP/1.0 200 OK in the header and "This is OK" in the body Actual result: -------------- HTTP/1.0 404 Not Found ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=47605&edit=1