error-handler-404 cannot change status code (introduced by 1.4.16)

[pierre]

Since lighttpd 1.4.16 an error-handler cannot change the 404 status code any more. This is needed if your handler wants to redirect to another site for example.

Think of a 404-handler which does the following:

<?php

header('HTTP/1.1 302 Found');          // shouldn`t be needed
header('Location: http://www.lighttpd.net');
exit();

?>

Using this script as an error-handler-404 lighttpd outputs the following when trying to access a nonexistent file:

HTTP/1.1 404 Not Found
Location: http://www.lighttpd.net
Content-type: text/html
Content-Length: 0
Date: Fri, 27 Jul 2007 18:36:10 GMT
Server: lighttpd/1.4.16

So it does not override the 404 status code. Browsers will ignore the Location when no 302 status code was sent.

This worked with version 1.4.15.

[jeremyevans]

Fix for redirect not working in 404 handler

[jeremyevans]

I can confirm the problem. Diffing 1.4.15 and 1.4.16 leads to the fairly obvious patch I just added that fixes it.

[darix]

and that will break bug #948 again. i still need to find time to fix this properly. sadly i am not allowed to remove the 404 handler hack infavor of mod_magnet. :(

[soulhunter]

Replying to darix:

and that will break bug #948 again. i still need to find time to fix this properly. sadly i am not allowed to remove the 404 handler hack infavor of mod_magnet. :(

this problem also broke rails. I just upgraded lighttpd, and now any "redirect_to" in rails, that used to work, no longer works :( . It worked on 1.4.15.

[darix]

Replying to soulhunter:

Replying to darix:

and that will break bug #948 again. i still need to find time to fix this properly. sadly i am not allowed to remove the 404 handler hack infavor of mod_magnet. :(

this problem also broke rails. I just upgraded lighttpd, and now any "redirect_to" in rails, that used to work, no longer works :( . It worked on 1.4.15.

you are using server.404-error-handler = "/dispatch.fcgi" right?

[soulhunter]

Replying to darix:

Replying to soulhunter:

Replying to darix:

and that will break bug #948 again. i still need to find time to fix this properly. sadly i am not allowed to remove the 404 handler hack infavor of mod_magnet. :(

this problem also broke rails. I just upgraded lighttpd, and now any "redirect_to" in rails, that used to work, no longer works :( . It worked on 1.4.15.

you are using server.404-error-handler = "/dispatch.fcgi" right?

yes.... why?

[darix]

Replying to soulhunter:

Replying to darix:

[snip]

you are using server.404-error-handler = "/dispatch.fcgi" right?

yes.... why?

the mod_magnet solution still works.

[rtomayko]

I assume by "mod_magnet solution," we're talking about this:

http://pixel.global-banlist.de/2006/10/6/dr-magneto-vs-mr-404-handler

I may give that a try. Unfortunately, there's no way I can push such a large change into production without significant testing so I'd much prefer to get a 404-handler fix in place for this.

Can someone elaborate on how jeremy's patch, which basically reintroduces #948, is a worse case than #1270? #948 seems minor compared to #1270. #1270 effectively breaks all of FCGI for configurations that rely on the 404 handler.

To be honest, I'm a bit confused by the whole series of events (or lack of events) since 1.4.16 was released. From what I can tell, #1270 should be breaking Rails apps everywhere but I've heard very little reported here, on the blogs, or on mailing lists. This leads me to believe that one of the following must be true:

1. There's not that many Rails apps running on lighttpd / FCGI anymore.

2. No one cares about the 1.4.15 vulnerabilities and haven't upgraded to 1.4.16.

3. People are actually running Rails behind 1.4.16 and unknowingly sending out 404's with every response.

4. People are running with the mod_magnet solution darix referenced earlier.

5. Everyone's running with jeremy's patch.

6. I'm missing something.

All of these seem quite unlikely -- I'm leaning toward #6.

Assuming I'm not missing something, I'd strongly recommend an immediate 1.4.17 release that incorporated jeremy's patch and regressed on #948. Either that or give some kinds of heads up that 1.4.16 is going break existing configurations and that the mod_magnet work-around could be a potential work-around.

[rtomayko]

So it seems there has been quite a bit of noise around this in the comments of the announcement... I just missed it:

http://www.lighttpd.net/2007/7/24/1-4-16-let-s-ship-it

Again, all of these comments assume that this is breaking redirect responses only but it's actually breaking all responses. The issue just isn't visible in the browser with 2xx status responses.

I'm going with jeremy's patch. If one of the lighttpd devs could keep this ticket updated with an official position or status, it'd be much appreciated.

[soulhunter]

Hi!

Well... the thing is: there are MANY documents out there that tell one to use "mongrel" in "production environments"... I actually installed mongrel in order to avoid the lighttpd problem, but I like lighttpd, so when this issue get fixed, I will go back to it.

Thanks!

[darix]

1. an official statement: we acknowledge it is an regression compared to 1.4.15. but there is at least a work around. we run very high traffic sites with mod_magnet without any problems.

2. yes it will be fixed in 1.4.17. but in a way that both bugs (#948 and this one) are fixed in the end.

3. (as answer for comment:9) you need lighttpd or some other proxy in front of your mongrel instances. as each mongrel instance can only handle 1 rails request at a time.

4. using the 404 handler for this still sucks. but sadly i am not allowed to remove it.

with kind regards,

your 1.4.x maintainer

[rtomayko]

Thanks darix. Let me know if I can help out. I'd be happy to take a stab at a patch that addressed #1270 and #948 with a point in the right direction. It goes without saying that I'd be more than willing to help test as well.

[anonymous]

I'm not convinced by your claim (#4) that the mod_magnet solution is preferable to be honest. It requires a lighttpd linked against lua, is measurably slower, requires a longer and less elegant configuration, and doesn't match up with the canonical route on any other webserver! Am I missing some advantage that outweighs all of these?

[darix]

Replying to rtomayko:

Thanks darix. Let me know if I can help out. I'd be happy to take a stab at a patch that addressed #1270 and #948 with a point in the right direction. It goes without saying that I'd be more than willing to help test as well.

http://trac.lighttpd.net/trac/changeset/1899

[darix]

Replying to anonymous:

I'm not convinced by your claim (#4) that the mod_magnet solution is preferable to be honest. It requires a lighttpd linked against lua,

true

is measurably slower,

it is slower in academic situations like hammering your server with 3000-4000 r/s

requires a longer

longer? it is one line, just as your 404 handler config

magnet.attract-physical-path-to = ( rails_root + "/cleanurl.lua" )

and less elegant configuration,

matter of taste.

and doesn't match up with the canonical route on any other webserver!

it is basically a more powerful way of doing that. without learning a new programming language as mod_rewrite on apache is.

Am I missing some advantage that outweighs all of these?

- in mod_magnet all return code work (404-handler breaks 403) - you can easily implement more complex logics (http://pixel.global-banlist.de/mephisto_multi.lua)

[anonymous]

Yes, definitely a longer configuration: you have a lua script cleanurl.lua in addition to your lighttpd.conf in your magnet solution, and this is itself part of your server configuation! It's unclear to me that 404-handler needs to break with respect to any error code. (I agree that, in practice, fixing the spaghetti in connections.c so neither bug #1270 nor bug #948 bite is a bit of a pain. I was just looking at it myself. Ouch.)

Mod_magnet is useful when the straightforward error handler is insufficient, and I agree it's nicer than an Apache-style mod_rewrite in that case, but it still seems like a power drill to crack a nut for the simple-minded rails /dispatch.fcgi.

[anonymous]

Aha. That's fixed it nicely. Thanks!

[darix]

can you please test svn r1904 of the 1.4.x branch?

I checked in a fix that now passes the 404-handler testsuite and fixes both #1270 and #948 . See this link how to get the svn branch.

[rtomayko]

darix: the latest lighttpd-1.4.x code fixes all issues w/ Rails using the 404 handler. Sending back 404 status responses through the dispatcher also seems to work as I would expect.

I'll be testing further in our staging environment. If all goes well, I'll probably deploy to production tonight.

For those using FreeBSD ports, here's a quick way to get the latest 1.4.x code in place:

$ sudo su -
# cd /usr/ports/www/lighttpd
# svn diff \
  svn://svn.lighttpd.net/lighttpd/tags/lighttpd-1.4.16 \
  svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x \
  > files/patch-404-handler.c
# portupgrade -f lighttpd # (or make clean install or whatever)

You'll basically be running the latest 1.4.x code.

Remember to remove files/patch-404-handler.c when lighttpd-1.4.17 comes down.

[darix]

Replying to rtomayko:

darix: the latest lighttpd-1.4.x code fixes all issues w/ Rails using the 404 handler. Sending back 404 status responses through the dispatcher also seems to work as I would expect.

yes. sending 404 from rails was broken before 1.4.16 (see bug #948)

i'm glad everything is working now. see the tests/core-404-handler.t file for all cases we check in the testsuite. if you see any case we have missed i would be glad to hear about it.