Skip to content

2007

  • 1 min read

Giving Solaris some love

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)
  • in releases
  • 1 min read

1.4.18 - speeding up a bit

“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 secweb.se 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.)

Download

  • lighttpd-1.4.18.tar.gz\ (sha1sum: 30eb24cdfcfeadf10fa16f187330bdc5deb25ed2\ md5sum: 5db3204d57436a032f899ff9dbce793f)
  • lighttpd-1.4.18.tar.bz2\ (sha1sum: a53a8f8ae8d42d036f0b5129764b822e943cc778\ md5sum: 26f98dddf9d8c0775221b800986003ee)
  • in releases
  • 2 min read

1.4.17 - for the sake of the server.error-handler-404

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.

Download

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

Thanks for using lighttpd! :)

1.4.16 - Let’s ship it

We all could use some refreshment in this hot summer. So how about a fresh and shiny new lighttpd release? Sadly the main reasons are again a few security fixes. (Bad developers, bad!) But we broke it, we fix it. On the other hand we squeezed in a new cool feature aswell. The E-Tag generation is now configurable. So if your files are on a NFS cluster you can now e.g. disable the inode number usage for the E-Tag.

Teh bugz!!!

header parsing bug
Lighttpd SA 2007:03\ (patch: lighttpd-1.4.x_duplicated_headers_with_folding_crash.patch)
various mod_auth bugs
Lighttpd SA 2007:04\ Lighttpd SA 2007:05\ Lighttpd SA 2007:06\ Lighttpd SA 2007:07\ (patch: lighttpd-1.4.x_mod_auth_sec.patch)
mod_access bug
Lighttpd SA 2007:08\ (patch: lighttpd-1.4.x_mod_access_bypass.patch)
mod_fastcgi local DOS bug
Lighttpd SA 2007:09 (patch: lighttpd-1.4.x_mod_fastcgi_local_dos.patch)

The reader might wonder now why we delayed the release that long. We actually tried to get CVE numbers for all the bugs, to avoid confusion later. But so far we did not succeed in receiving them. As the bugs got publically announced now, we are forced to release.

External references

Download

  • lighttpd-1.4.16.tar.gz\ (sha1sum: b160cece6c0dd15746d10957d28ba02b2e9e77ce\ md5sum: 04988067026e93ccb46e19fa8c17ae97)
  • lighttpd-1.4.16.tar.bz2\ (sha1sum: 8f137ff71f629fe24a745c758b72dce24a8669f2\ md5sum: ea671997591f772417b7e540d325f8cc)

Thanks for using lighttpd! :)

Lighttpd 1.4.15 - The “following traditions” release

Here we are again. As a good tradition with lighttpd release we are bitten by a last minute hotfix in 1.4.14. :)

The bug appeared in 1.4.14 and users of 1.4.13 or older releases are not affected.

You can read up on the other 1.4.14 changes here.

Download

  • lighttpd-1.4.15.tar.gz\ (sha1sum: 67ba1279a0eaeda728c1e1143d302beb364a034c\ md5sum: d2ceaaf242b2b3593ff4d8222d543649)
  • lighttpd-1.4.15.tar.bz2\ (sha1sum: 742b567eca011fa5ef2cc506038389a4959eab56\ md5sum: b994b8c359da578dec073cae52c4924f)

Thanks for using lighttpd! :)

thread starvation

While running several benchmarks I saw that http_load was getting time outs for some of the connections. This has been seen with all web-servers and different backends in lighttpd as well.

After patching http_load to handle timed out and byte count errors correctly, I could easily separate the time outs from other problems. In one of the last changesets I added a infrastructure to track the time spent in lighttpd for a single connection including the time spent in the different stages of the gthread-aio backend:

  • scheduling the threaded-read()
  • starting the read() in the thread
  • waiting until it is finish
  • sending the result into the main-loop
  • writing the buffered data to the socket

buffered IO performance

Next to the raw-IO performance which is important for heavy, static file transfers the buffered IO performance is more interesting for sites which have a small set of static files which can be kept in the fs-caches.

As we are using hot-caches for this benchmark the “lightness” of the server becomes important. The less syscalls it has to do, the better.

The test-case is made up of 100MByte of files in the size of 10MByte and 100kByte.

raw IO performance

In lighttpd 1.5.0 we support several network backends. Their job is to fetch static data from disk and send it to the client.

We want to compare the different backends for their performance and when you want to use which.

  • writev
  • linux-sendfile
  • gthread-aio
  • posix-aio
  • linux-aio-sendfile

The impact of the stat-threads shall also be checked.