Skip to content

1.4.12 becomes 1.5.0

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.