Project

General

Profile

Bug #1828

REDIRECT_STATUS == 200 on 404 redirect

Added by Malvineous over 8 years ago. Updated about 1 year ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
core
Target version:
Start date:
2008-11-25
Due date:
% Done:

100%

Estimated time:
Missing in 1.5.x:

Description

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"

PHP:
echo $_SERVER['REDIRECT_STATUS'];
?>

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.

Associated revisions

Revision 5492063f (diff)
Added by gstrauss about 1 year ago

[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.

x-ref:
"REDIRECT_STATUS == 200 on 404 redirect"
https://redmine.lighttpd.net/issues/1828

github: closes #35

History

#1 Updated by bestis over 8 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

#2 Updated by Mozai almost 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 are out of luck.

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.

#3 Updated by Malvineous over 5 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.

#4 Updated by gstrauss over 1 year 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.

#5 Updated by gstrauss about 1 year ago

  • Target version set to 1.4.40

#6 Updated by gstrauss about 1 year ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

Also available in: Atom