Ladies and Gentlemen, Spambots and Jackalopes, may we have your valuable attention please.

As you may have noticed, our trac was painfully slow most of the time and we missed some features that we would like to have. So we looked for alternatives and found Redmine

It took some effort to migrate everything from trac to it but now most of it is done. Some wiki pages couldn’t be converted 1:1, so we ask you to fix the formatting issues if you come across any and know how to do so.

Redmine also allows us to get rid of the old forums that had serious spam problems in the past.

trac.lighttpd.net will be read-only from now on and forum.lighttpd.net will probably be gone for good or read-only too.

So, without further ado, we want to unveil our new project haven.

Hope you like it and thanks for using lighty.

Just in case you didn’t see the announcement on the main page: click

Please head over there for more information.

If you want to get the latest source for any branch, you can get it from our svn repository.
Documentation to do so can be obtained from this page:
http://trac.lighttpd.net/trac/wiki/Devel/Subversion
Bug reports or feature requests can be filed in our trac ticket system:
http://trac.lighttpd.net/trac/newticket
Please make sure to check if there isn’t a ticket already here:
http://trac.lighttpd.net/trac/report

Thank you for flying lighty airlines.

We would like to draw your attention to the latest prerelease of the 1.4 branch of lighttpd.

Again, you can get the prerelease from this url: http://opensu.se/~darix/lighttpd/

It should be the last prerelease and a final 1.4.20 to be released soon.

Changelog since last prerelease:

• do not send content-encoding for 304 (#1754), thx yzlai
• fix segfault for stat_cache(fam) calls with relative path (without ’/’, can be triggered by x-sendfile) (#1750)
• fix splitting of auth-ldap filter
• workaround ldap connection leak if a ldap connection failed (restarting ldap)
• changed parser generation again as the previous fix broke building with some non-gnu make utils

If you want to get the latest source for any branch, you can get it from our svn repository.
Documentation to do so can be obtained from this page:
http://trac.lighttpd.net/trac/wiki/Devel/Subversion
Bug reports or feature requests can be filed in our trac ticket system:
http://trac.lighttpd.net/trac/newticket
Please make sure to check if there isn’t a ticket already here:
http://trac.lighttpd.net/trac/report

Thank you for flying light.

I’m sure you know what “Crawl-Delay” is, but you may or may not know that, not all search engine crawlers support this nice stuff.

What to do for those don’t obey the instrustion? They’ll eat all your Mbits/month or slow your webserver down. OK, ban it with url.access-deny. This is the only option u can choose before. But you don’t want to remove your pages from the stupid search engine index, do you?

Here comes another option for you: with this patch, u can delay handling of a specified request for some seconds. Example configuration:

OK, here’s the link to the lighttpd-2296-request-handle-delay.patch which applies to branches/lighttpd-1.4.x@2296

Be aware that this patch is to be reviewed before commited to repo.

It’s been some time since the last 1.4 release and especially since the last 1.5 prerelease. There have been a lot of fixes in both branches so be sure to check them out, no matter if you are using 1.4 or 1.5.

You can get the prereleases from this url: http://opensu.se/~darix/lighttpd/

The 1.4.20 changes can be read here:
http://trac.lighttpd.net/trac/browser/branches/lighttpd-1.4.x/NEWS
While 1.5 changes can be fetched from here:
http://trac.lighttpd.net/trac/browser/trunk/NEWS

We ask you to test these snapshots as extensive as possible and report any broken things back to us.
If everything goes well and no showstoppers are encountered, there will be an official 1.4.20 release soon.

As for 1.5: should this prerelease be stable and bugfree enough, it will be the last prerelease and there will be a 1.5.0 release. It will not retire the 1.4 branch though. There are still some things missing in 1.5 like internal spawning of fcgi backends that prevent it form being the next main branch.

You can thank stbuehler for all his hard work he has put into both trees as he is responsible for nearly all of the work recently.

If you want to get the latest source for any branch, you can get it from our svn repository.
Documentation to do so can be obtained from this page:
http://trac.lighttpd.net/trac/wiki/Devel/Subversion
Bug reports or feature requests can be filed in our trac ticket system:
http://trac.lighttpd.net/trac/newticket
Please make sure to check if there isn’t a ticket already here:
http://trac.lighttpd.net/trac/report

Thank you for using lighty.

• hoffie
• icy
• nitrox
• stbuehler

If you hang out in #lighttpd, you will already know these names.

That being said, there is also some news about the state of the development of lighty.

Lighty is a great webserver and we all love it. But if you use it for quite some time, you’ll eventually find out that it’s not perfect. There are some oddities and shortcomings that cannot be ironed out without rewriting a significant part of the core.

This is where I had the idea to start all over. With lessons learned from the past, we could write a new version of lighty that fixes the design issues the current versions have. But at the same time keep all the good stuff and remain fairly compatible. The main idea to be fast and lightweight is still valid and if you are familiar with 1.4.x or 1.5, you will have no problems with the new version.

Jan had the idea to use glib for stuff like strings/buffers and arrays. He wanted to rewrite the corresponding parts and did so in a branch of his. I proposed to take this even further and use glib throughout the source. It makes coding easier, faster and in the end more secure because you can rely on proven and well tested source.

stbuehler jumped in and created a new branch where he started to hack on an all new lighty using the ideas from above. The following days we discussed a lot – and still do so – about the new design. What we could do better, what shortcomings we wanted to fix.

The result is nothing less but a more flexible and faster design for lighty.

This sounds awesome but where is the catch you might think. Well, currently we have not too much code ready but we are actively hacking on it. Do not ask when it will be released, there is no estimated date. We are still at the very beginning of the new version but hope to have it some day become the official Lighttpd 2.0

We created a page that lists some of the (technical) plans we currently have. You might find some of them interesting.

This is it for today folks. Hope you like the route we are taking and maybe drop us a line in #lighttpd (freenode) or in the comments.

After quite some time lighttpd is moving forward again. Please give this pre-release a try and check if it drops in nicely and doesn’t cause any new issues.

It is mostly a bug-release and we want to make sure it is a good release. If this pre-release passes your tests, we’ll put the real release online in a few days.

Download: http://opensu.se/~darix/lighttpd/

ChangeLog: http://trac.lighttpd.net/trac/browser/branches/lighttpd-1.4.x/NEWS

Google is doing a the Summer of Code again and I was approached from different sides to participate this year. There is already a lot going on in SVN again working towards a new 1.4.19 release, but for the future we want to attract more developers for more new, great features.

Before I submit the application request I would like to collect some more ideas what we would like to see to be done. At GSoC2008/Ideas I added my short list of projects that I would like to mentor.

If you would like to be a mentor too, please add your own list.

• Documentation improvements
• Integration into web-panels
• maintaining the OpenWRT port

are just some small ideas where we could take help from non-developers.

Part of my ongoing, hidden effort to port lighttpd to glib I can now at least say: it compiles.

Well, mostly. The core does compile and mod_staticfile is also mostly done. Mostly, as I don’t have decided on how to handle the config-file handling yet.

So, what has been done so far:

• buffer.c and buffer.h are gone and are replaced by GString
• array.c is gone and is replace by GHashTable or GPtrArray
• array.h will vanish when the data_…c goes away
• log.c is now a wrapper around g_log_…

As you see this is ripping out the basic data-structures and replaces them by a glib look-alike.

This isn’t just a drop-in replacement as the structures use other field-names and sometimes have a slightly different meaning.

One example is GString vs. buffer:

While str and ptr, and allocated_len and size match, used and len differ by one byte (used includes the NUL-byte, len doesn’t).

One side-effect of this boring work is seeing the code-size shrinking, piece by piece.

Seeing old, sometimes dirty code vanish is another nice side-effect. Like the log_error_write() call … man …