Skip to content

2008

A little heads up

Hey folks,

back in july, I posted about a new lighty branch we planned on creating. A complete rewrite with a new core design.
There haven’t been any posts since then about it and you might wonder if it lead to anything.

Well, roughly 4 months, 256 commits and 14 thousand lines of code later, we are at a point at which we have something to show you.
We just opened up our project in redmine to the public: https://redmine.lighttpd.net/wiki/lighttpd-sandbox
You can take a look around and browse the source.
We call it “sandbox” because there is one thing we want to really stress: it is not in a useable state yet. Boards as well as ticket/issue tracking have been disabled for it because we are not capable of providing any support at this point.
I repeat: NO SUPPORT FOR SANDBOX
So what state is it in exactly?

  • the config handling is pretty complete
  • basic connection handling including throttling and keep-alive/IO timeouts works
  • error logging works (introducing multiple error log levels and targets)
  • module/plugin interface mostly done
  • completely multithreaded
  • serves static files

I am currently working on the new mod_accesslog. It is already capable of what the 1.x version can but I wanted to expand it a little bit.
A feature that might be quite usefull: have different log formats and targets depending on the status code of the request. This way, you can for example log all request resulting in a 400 or 500 to a special file with addition information you would normally not log.
But I have trouble finding the right way to express that in the config in a good way. This is the perfect moment to get you users out there involved. I’d really like to hear your suggestions so please leave a comment with your ideas. Take a look at the config documention in the sandbox wiki to know what you can use.

A lot of work has been done and there is even more still ahead. It really takes a lot of time and hopefully it will pay off some day.\

So much for the bleeding edge part. About 1.x: There will probably be a 1.4.21 (pre)release soon. Watch out :)

We really would appretiate if more users would test our prereleases and report back to us if they find any issues. It’s crucial in order to bring you well-tested and stable releases.
A thank you to all the people who did this in the past at this point!

This is it for today.

Thanks for using lighty.

  • in hosting
  • 1 min read

Going to mine

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.

delay request handling for stupid crawlers

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:

$HTTP["user-agent"] =~ "stupid-crawler" {
    connection.delay-seconds = 2
}

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.

Growing the team

The dev team has gotten some new members recently that you might not know of. Here’s a heads up (in alphabetical order):

  • 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 “Plans_for_2_0” 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 or in the comments.

- update -

To make it clear: 1.5 or 1..4 have not been dropped. If you think 1.5 is unstable and you get a segfault or something like that, then tell us. File a ticket, attach a stacktrace and document the problem in a detailed way so it can be fixed. Thanks for using lighty.

PRE-RELEASE: lighttpd-1.4.19-r2118

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.

GSoC: collecting ideas

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.

Project Glib: it compiles … mostly

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.