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.