REDIRECT_STATUS == 200 on 404 redirect
When using a PHP script to handle a 404 redirect, the redirect status is incorrectly set to 200, instead of the status that caused the redirect. This is contrary to Apache's behaviour (I have a script that works under Apache but breaks under Lighttpd because of this.)
Steps to reproduce:
Add this line to lighttpd.conf:
server.error-handler-404 = "/path/to/file/below.php"
Vising http://server/blah will print 200 under lighttpd, and 404 under Apache. (The config line to test in Apache is "ErrorDocument 404 /path/file.php" in a Location section.)
I see there's a similar entry in the FAQ explaining why this is the case, but IMHO this is still broken behaviour and should be fixed to retain compatibility with existing PHP scripts.
[core] set REDIRECT_STATUS to error_handler_saved_status (fixes #1828)
set REDIRECT_STATUS to con->error_handler_saved_status in dynamic
handlers for PHP compiled with --force-redirect. Set to "200"
if (0 con->error_handler_saved_status)
(mod_cgi, mod_fastcgi, mod_scgi, mod_ssi)
FYI: setting REDIRECT_STATUS in con->environment allows access and
manipulation by mod_magnet.
"REDIRECT_STATUS 200 on 404 redirect"
github: closes #35
Updated by bestis over 9 years ago
Also I would like to see possibility to change that in lua (have searched but haven't found it).
So when stat fails in lua it could be set to 404 when making a redirect there.
attr = lighty.stat(lighty.env['physical.path']) if (not attr) then -- file still missing. pass it to the fastcgi backend lighty.env["uri.path"] = "/index.php" lighty.env["physical.rel-path"] = lighty.env["uri.path"] lighty.env["request.orig-uri"] = lighty.env["request.uri"] lighty.env["physical.path"] = lighty.env["physical.doc-root"] .. lighty.env["physical.rel-path"] -- like this or something: lighty.env["request.status"] = 404 end
Updated by Mozai over 6 years ago
With PHP you can work around this bug by putting this at the top of your script:
<?php header(‘HTTP/1.0 404 Not found’); ?>
Something similar can be done for CGI. People wishing to use static html error messages
EDIT: I read the FrequentlyAskedQuestions; now I have an answer for those who are not using PHP. For custom error messages, one should use "server.errorfile-prefix" instead, and have files named "404.html", "403.html", "500.html" etc in that directory.
I was confused by the name "server.error-handler-404" since I thought it was for reporting 404 errors, but the FAQ tells me it's actually for creating new pages to replace 404 errors.
Updated by Malvineous over 6 years ago
Unfortunately your solution doesn't address the problem. Your code returns a HTTP 404 error to the browser, but the bug is about detecting the error code that caused your script to be called in the first place.
For example if you have server.error-handler-404="index.php" and then you visit http://yoursite/index.php followed by http://yoursite/badpage both times index.php will be called, but $_SERVER['REDIRECT_STATUS'] will be 200 both times, so you don't know whether you're being called directly or as the result of a 404 redirect.
Under Apache, the second URL will set $_SERVER['REDIRECT_STATUS'] to 404 so you know the script is being called as the result of a 404 redirect.
Some content management systems use this for 'friendly URLs', so these systems cannot run correctly under lighttpd.
Updated by gstrauss about 2 years ago
Submitted https://github.com/lighttpd/lighttpd1.4/pull/35 to set REDIRECT_STATUS to HTTP status code for access by server.error-handler-404. Currently, the only values will be 403 or 404, as those are the HTTP status codes intercepted by server.error-handler-404.
Also available in: Atom