Giving Solaris some love

October 28, 2007

Weekend time is hacking time. This weekend it is about getting 1.5.0 running nicely on Solaris and making sure lighttpd is a first class citizen there.

All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED), 88 subtests skipped.
Files=22, Tests=324, 60 wallclock secs ( 1.98 cusr +  1.03 csys =  3.01 CPU)

1.4.18 - speeding up a bit

September 09, 2007

"Release early, release often."

So here we are again. The previous release is already 12 days old! It already got grey hair.

And again we have a small security bug! It seems, if you get the more popular, more people are looking at your code. This time Mattias Bengtsson and Philip Olausson from took a look at the code. They found a small bug that could lead to remote code execution in fastcgi applications. (We wont mention names here.)


  • lighttpd-1.4.18.tar.gz
    (sha1sum: 30eb24cdfcfeadf10fa16f187330bdc5deb25ed2
    md5sum: 5db3204d57436a032f899ff9dbce793f
  • lighttpd-1.4.18.tar.bz2
    (sha1sum: a53a8f8ae8d42d036f0b5129764b822e943cc778
    md5sum: 26f98dddf9d8c0775221b800986003ee


  • fixed compile error on IRIX 6.5.x on prctl() (#1333)
  • fixed forwarding a SIGINT and SIGHUP when using max-workers (#902)
  • fixed FastCGI header overrun in mod_fastcgi (reported by
  • fixed hanging redirects with keep-alive due to missing "Content-Length: 0" headers
  • fixed crashing when using undefined environment variables in the config
  • fixed compilation of mod_mysql_vhost on irix (#1341)

For all the packagers: if you wonder what happened to lighttpd 2007-SA:11 and lighttpd 2007-SA:10, they will be released in the next days.

Ok. We broke it. And yes it took longer than expected to fix it.

Anyway. It was worth to wait. We fixed lots of bugs in this release. For a complete list of changes see below.

The final fix for bug #948 changed the behavior of the server.error-handler-404. In the past lighttpd tried to send 404 responses generated by CGI/FastCGI/SCGI applications to the configured handler. With the current design of the plugin handling the 404 handler this failed, if the subrequest used the same backend as the original request (FastCGI -> FastCGI 404 handler). Starting with 1.4.17, only the original request will trigger the 404 handler. That means your application has to generate the content for the 404 response itself. You can no longer rely on the 404 handler for dynamically generated 404 responses.


  • lighttpd-1.4.17.tar.gz
    (sha1sum: f86684db6979c363d74689a51c3e8a7af066025e
    md5sum: 7172c39c2a166fe7f9ab6df30fa4298f
  • lighttpd-1.4.17.tar.bz2
    (sha1sum: e7684d29b2a42bc0628dc59b05741fc5fb5f699b
    md5sum: 85c99c2d6baf8ad9e38e6267efe7d9aa

Thanks for using lighttpd! :)