lighty's life: 1.4.12 becomes 1.5.0

1.4.12 becomes 1.5.0

jan — Wed, 26 Jul 2006 22:41:00 +0000

moo poked me today and was so right: “With all the changes going into SVN we shouldn’t call the next release 1.4.12, but 1.5.0”. Lifting the restriction on ‘try to stay compatible to the 1.4.x plugin-API I started right away on ripping the internals apart and put them together sliglty different.

If you are developing a plugin for 1.4.x right now, be asured that it won’t work without changes in 1.5.0. Let me explain what is changing.

The major change for the plugin developers are 3 or 4 things:

the fdevent-handling interface is simpler now and hides the nasty details. You only provide a iosocket
chunkqueues everywhere and no direct call to write() or read() on a socket. This is all done through the network_* interface. You don’t have to care about platform dependent functions.
there is a lemon-based HTTP-Response parser (see mod_proxy_core)
TRACE ( ) and ERROR ( ) instead of log_error_write(...)

All this is in SVN already. Some other changes are coming up right now and are mostly around the central state-engine and how a request is steps through the server. Currently we have these steps:

accept connection
read request header + request content
call backend and send all the data
read backend response and prepare response header
send response to the client
on keep-alive go to 2, otherwise close the connection

What I currently implement is slightly different:

accept connection
read the request header
set up the request-handling filter-chain
forward request content to the backend
read the backend response header
set up the the response-handling filter-chain
forward the response content to the client
on keep-alive go to 2 otherwise close the connection

This follows a simple idea: ‘After parsing the HTTP-headers you have all the information on how you want to continue to handle the request.’ All plugins will get called and can hook into the filter-chain.

mod_uploadprogress will hook into the request-filter-chain to track to progress of connections
mod_deflate will replace content in the response-filter-chain
mod_demux will split a proxy-response into multiple client responses
mod_http_chunking will provide generic HTTP/1.1 chunking

It will be left to backend when they want to make the connection to the backend:

when they have the request header
when they have a part of the request-content (POST body)
when they have the full request-content as now

What else will change ?

the hand-written HTTP-request parser will get kicked out in favour of a lemon based one. We already have one for the HTTP-responses and can use most of its code.

"1.4.12 becomes 1.5.0" by Alex

Tue, 15 Aug 2006 06:45:34 +0000

How soon can we expect version 1.5?

"1.4.12 becomes 1.5.0" by A1eX

Fri, 11 Aug 2006 13:39:16 +0000

Oh cool a new version soon ! And what about .htaccess support? (perhaps with lighty's pattern style for rewriting urls) It's the only thing missing in lighty that makes a lot of people continue to use apache...

"1.4.12 becomes 1.5.0" by jan@kneschke.de

Fri, 11 Aug 2006 11:55:54 +0000

I don't know if the current code still compiles on win32 nativly, but a while ago it was compiling and working (all but spawning processes). So, perhaps we have a native win32 version somewhen in the 1.5.x release cycle.

"1.4.12 becomes 1.5.0" by Rio

Fri, 11 Aug 2006 05:29:52 +0000

Cool! what about native Win32 support?

"1.4.12 becomes 1.5.0" by Jan Kneschke

Thu, 03 Aug 2006 10:56:30 +0000

Up to now I'm not aware of any complaints about mod_flv_streaming. Whay should be improved ?

"1.4.12 becomes 1.5.0" by video

Mon, 31 Jul 2006 23:31:35 +0000

Good job.I want to know are there any improvements on Flv stream model?

"1.4.12 becomes 1.5.0" by Jan Kneschke

Mon, 31 Jul 2006 11:35:53 +0000

The lemon based parser is more strict and easier to maintain than the old hand-written one. Hand-written parsers are only better and faster if the implementor knows how to write a parser. To be honest ... lemon does this better than me. :) For the configfile: All these changes should only care plugin developers. The configfile will stay the same.

"1.4.12 becomes 1.5.0" by Sencer

Sun, 30 Jul 2006 15:55:39 +0000

Does the renaming only reflect changes already done, or will it delay the next release further due to other changes you want to get into the 1.5.x series? Are you shooting for a concrete date in terms of releasing 1.5.0?

"1.4.12 becomes 1.5.0" by Marco Rodrigues

Sun, 30 Jul 2006 09:48:04 +0000

How about to include configuration for php5-fastcgi ? not only php4-fastcgi.. Here is the code of the script: ## FastCGI programs have the same functionality as CGI programs, ## but are considerably faster through lower interpreter startup ## time and socketed communication ## ## Documentation: /usr/share/doc/lighttpd-doc/fastcgi.txt.gz ## http://www.lighttpd.net/documentation/fastcgi.html server.modules += ( "mod_fastcgi" ) ## Start an FastCGI server for php5 (needs the php5-cgi package) fastcgi.server = ( ".php" => ( "localhost" => ( "socket" => "/tmp/php5-fcgi.socket", "bin-path" => "/usr/bin/php5-cgi" ) ) ) I've tested this on Ubuntu v6.06 LTS.

"1.4.12 becomes 1.5.0" by Rolf Bode-Meyer

Sat, 29 Jul 2006 11:52:23 +0000

"the hand-written HTTP-request parser will get kicked out in favour of a lemon based one." Urm, what's the benefit? Isn't hand-written nearly almost always faster and better fitting? Is lighty one of the cases where this isn't true, or do we have to reckon with lower performance if generated parsers take over the code?

"1.4.12 becomes 1.5.0" by Imran

Sat, 29 Jul 2006 02:43:46 +0000

Do we need to do any changes if we've not got anything special done on our CONFIG files other than standard virtual hosting ?