1.4.12 becomes 1.5.0 11

Posted by jan Wed, 26 Jul 2006 20:41:00 GMT

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:

  1. the fdevent-handling interface is simpler now and hides the nasty details. You only provide a iosocket
  2. 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.
  3. there is a lemon-based HTTP-Response parser (see mod_proxy_core)
  4. 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:

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

What I currently implement is slightly different:

  1. accept connection
  2. read the request header
  3. set up the request-handling filter-chain
  4. forward request content to the backend
  5. read the backend response header
  6. set up the the response-handling filter-chain
  7. forward the response content to the client
  8. 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.
Trackbacks

Use the following link to trackback from your own site:
http://blog.lighttpd.net/articles/trackback/1850

Comments

Leave a response

  1. Imran Sat, 29 Jul 2006 00:43:46 GMT
    Do we need to do any changes if we've not got anything special done on our CONFIG files other than standard virtual hosting ?
  2. Rolf Bode-Meyer Sat, 29 Jul 2006 09:52:23 GMT
    "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?
  3. Marco Rodrigues Sun, 30 Jul 2006 07:48:04 GMT
    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.
  4. Sencer Sun, 30 Jul 2006 13:55:39 GMT
    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?
  5. Jan Kneschke Mon, 31 Jul 2006 09:35:53 GMT
    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.
  6. video Mon, 31 Jul 2006 21:31:35 GMT
    Good job.I want to know are there any improvements on Flv stream model?
  7. Jan Kneschke Thu, 03 Aug 2006 08:56:30 GMT
    Up to now I'm not aware of any complaints about mod_flv_streaming. Whay should be improved ?
  8. Rio Fri, 11 Aug 2006 03:29:52 GMT
    Cool! what about native Win32 support?
  9. jan@kneschke.de Fri, 11 Aug 2006 09:55:54 GMT
    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.
  10. A1eX Fri, 11 Aug 2006 11:39:16 GMT
    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...
  11. Alex Tue, 15 Aug 2006 04:45:34 GMT
    How soon can we expect version 1.5?
Comments