Lighttpd

Has this bug been fixed since 1.4.9 ?

I'm using 1.4.11_1 (ssl) on FreeBSD 6.1, the bug seems to be persist here.... :-(

-- Ricky Sun

this is still present on the last release and the semantics of a fix are complicated by the fact that the fastcgi processes are independent of lighttpd (could be started independently or even reside in a different server and communicate using a tcp socket).

still, as described on the bug report, for the cases where lighttpd spawns the fastcgi processes and they run locally (using either a unix or a tcp socket) then when possible, the stderr for the fastcgi processes should be linked to the error log (to mimic compatibility with mod_cgi) even though the recommended way to send errors from the fastcgi applications should be by generating FCGI_STDERR as described in BUG998 and as described by the fastcgi spec.

-- carenas

just to clarify:

sending errors directly to the log violates the fastcgi specification as it specifically says that stderr should be closed and therefore lighttpd's implementation was buggy just because it was leaving stderr open and connected to the controlling terminal.

a correctly written fastcgi application should be able to send the errors to lighttpd using FCGI_STDERR packets by calling the right interface and therefore the fact that the errors were being written to the controlling terminal and not the log means that the fastcgi application was buggy as well.

attached a patch for lighttpd 1.4.9 that closes stderr correctly and therefore prevents the messages to get printed in the console, but that doesn't violate the spec by sending those messages to the log directly.

for details on how to fix the fastcgi application bug refer to ticket 998 test cases or to the fastcgi documentation

Yes, a properly written FastCGI app will never produce output to stderr. However, the point of sending stderr output to the log (which of course we can do only when lighttpd is the one starting the FastCGI server) is to help people debug FastCGI apps that are broken or running on misconfigured systems.

Take as an example one that starts up and then discovers it can't load a necessary FastCGI library: it has no way to report this error via the FastCGI protocol, because it doesn't have any code for it. So it will likely try its best and print an exception or whatever to stdout, and exit with an error code.

Here lighttpd has two choices. One is to say, "the user misconfigured his application, it's not my problem," and do nothing, and the other is to try to collect whatever information is there, be it gotten in a FastCGI-standard-compliant way or not, and log it.

"Be liberal in what you accept, and conservative in what you send."

-- cjs