Php fastcgi error header
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: --------------- ); 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 )
Patches
Pull Requests
History
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
Automatic comment on behalf of bukka Revision: https://github.com/php/php-src/commit/5a4520bc2bc1698c4e7d1dc19956ce5519331e02 Log: Fix bug #68207: Setting fastcgi.error_header can result in a WARNING
How to Fix ‘Failed to read FastCGI header’ Apache Error
If you see the error «Failed to read FastCGI header» in your app’s Apache error log file at log/APPNAME/APPNAME_apache.error.log, there are three most likely causes:
- A bug in the app’s PHP code, such as a buggy WordPress plugin
- A bug in a PHP extension you’ve added to your server
- Your server running out of memory
When this error occurs, the response sent to the browser will be «503 Service Unavailable».
What the Error Means
The error message «Failed to read FastCGI header» means that when Apache was communicating with PHP-FPM, the PHP process did not respond properly.
This error does not mean there is a problem with Apache.
Diagnosing Buggy PHP Code
The most common cause of these errors is buggy PHP code in your app.
The best solution is to disable all WordPress plugins, custom themes, and other custom code until you identify which code is causing the problem.
You may find more information in the app’s PHP error log or PHP slow log. You can find these log files at:
/srv/users/SYSUSER/log/APPNAME/APPNAME_phpX.Y.error.log /srv/users/SYSUSER/log/APPNAME/APPNAME_phpX.Y.slow.log
where «X.Y» is the version of PHP your app uses, for example «5.6».
If you see errors in these files, it likely means you have a bug in your app’s PHP code, such as in a WordPress plugin.
For example, if you have slow scripts, a cascade of problems caused by the slow scripts can ultimately result in PHP not able to respond to requests anymore. In this case, the solution is to fix the slow PHP code.
Diagnosing Buggy PHP Extensions
If you have added custom PHP extensions, such as New Relic or any PECL extension, one of them may be buggy. If you are using any third-party extensions, see our article on identifying problematic PHP extensions.
Running Out of Memory
If your server runs out of memory when handling a PHP request and the PHP process was using a lot of memory, the PHP process handling the request will crash.
If you see errors like Out of memory: Kill process . (php-fpm) in your server’s /var/log/syslog file, this is the cause of the errors you’re seeing.
The best solution in this case is to upgrade your server to one with more memory.
Restarting PHP
Even if you haven’t identified the cause of the problem, you may be able to get your app working again by restarting PHP.
To restart PHP, SSH into your server as root and run the following command as root for your app’s PHP version (replace «X.Y» with the PHP version, for example «5.6»).
sudo service phpX.Y-fpm-sp restart
Note that if you haven’t identified and fixed the underlying cause of the problem, such as the buggy PHP code or PHP extension, the problem may happen again.