Bug #68207 [Opn->Asn]: Setting fastcgi.error_header can result in an E_WARNING being triggered

Edit report at https://bugs.php.net/bug.php?id=68207&edit=1 ID: 68207 Updated by: bukka@php.net Reported by: nj506 at zepler dot net Summary: Setting fastcgi.error_header can result in an E_WARNING being triggered -Status: Open +Status: Assigned Type: Bug Package: FPM related PHP Version: 5.5.17 -Assigned To: +Assigned To: bukka Block user comment: N Private report: N New Comment: Apology for more than 8 years of silence. Seems like the reported example actually works (at least on PHP 8) as FPM flushes headers at the end of request. There is an edge case with fastcgi_finish_request() which I fixed in the linked PR so it will no longer emits any headers sent warning. During this investigation I also noticed another problem with fastcgi.error_header which I create an issue for: https://github.com/php/php-src/issues/9981 Previous Comments: ------------------------------------------------------------------------ [2022-11-21 14:01:35] bukka@php.net The following pull request has been associated: Patch Name: Fix bug #68207: Setting fastcgi.error_header can result in a WARNING On GitHub: https://github.com/php/php-src/pull/9980 Patch: https://github.com/php/php-src/pull/9980.patch ------------------------------------------------------------------------ [2014-10-10 14:07:49] nj506 at zepler dot net Description: ------------ With fastcgi.error_header set to some value (e.g. "HTTP/1.1 500 Internal Server Error"), PHP-FPM will attempt to set the header value when the PHP exit status is determined to be 255 - https://github.com/php/php-src/blob/f89ee8040a8b8d93981c9df85a79592ceac02f1f/sapi/fpm/fpm/fpm_main.c#L1950-L1958 If headers have already been sent, then an E_WARNING is triggered by sapi_header_op - https://github.com/php/php-src/blob/f89ee8040a8b8d93981c9df85a79592ceac02f1f/main/SAPI.c#L675-L686 As such, if headers have been sent (e.g. due to output), then at some point PHP sets the exit_status value to 255 (e.g. due to an error), and fastcgi.error_header is set to some value, then an E_WARNING will be triggered. This seems undesirable - perhaps it should simply not attempt to call sapi_header_op if headers have already been sent? Test script: --------------- <?php // With fastcgi.error_header set to "HTTP/1.1 500 Internal Server Error" echo 'x'; register_shutdown_function(function() { file_put_contents('/tmp/error', print_r(error_get_last(), true)); }); z(); // trigger a fatal error Expected result: ---------------- A fatal error will be triggered, and the last error visible when shutting down will be the fatal. e.g. $ cat /tmp/error Array ( [type] => 1 [message] => Call to undefined function z() [file] => .../test.php [line] => 7 ) Actual result: -------------- PHP-FPM attempts to replace the header, but headers have already been sent (due to output): $ cat /tmp/error Array ( [type] => 2 [message] => Cannot modify header information - headers already sent by (output started at test.php:3) [file] => Unknown [line] => 0 ) ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=68207&edit=1