The post Nginx sets HTTP 200 OK on PHP-FPM parse errors appeared first on ma.ttias.be.
Here's an interesting bit of behaviour that I haven't been able to figure out yet. When a PHP error occurs in a PHP-FPM pool, nginx would still reply with a HTTP 200 status code -- indicating everything is OK.
For instance:
php-fpm-error.log: [error] 24802#0: *7 FastCGI sent in stderr: "PHP message: PHP Parse error: syntax error, unexpected '<' in test.php on line 3" while reading response header from upstream, client: 127.0.0.1, server: , request: "GET /test.php?time=1421685293 HTTP/1.1" nginx-access.log: 127.0.0.1 - - [...] "GET /test.php?time=1421685293 HTTP/1.1" 200 110 "-" "curl"
The actual response seen by the client shows the exact same HTTP 200 OK Status code.
$ curl -i localhost/test.php?time=`date +%s` HTTP/1.1 200 OK Server: nginx ... Parse error: syntax error, unexpected '<' in test.php on line 3
Enabling or disabling PHP's display_error
option didn't seem to make any difference.
This happens with a default nginx config, using an upstream
to pass all requests to the FastCGI PHP-FPM server. FastCGI's fastcgi_intercept_errors
is not being set, so it's still the default "off" (meaning nginx won't intercept any logs and should pass them on without modifying).
upstream php_fpm { server unix:/var/run/php-fpm/fpm.sock; } ... server { ... location ~ \.php$ { fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; fastcgi_read_timeout 30; if (-f $request_filename) { fastcgi_pass php_fpm; } } }
Anyone else noticing this? What's the best practice to let nginx respond with an HTTP 500 Internal Server Error
for these kind of PHP-FPM errors? A similar config in Apache responds correctly with an HTTP 500 code.
The post Nginx sets HTTP 200 OK on PHP-FPM parse errors appeared first on ma.ttias.be.