lighty's life

lighty developer blog

The New Mod_proxy_core

One thing I heard from everyone at the railsconf was: __Please fix mod_proxy__. In my talk I presented a look into the future and how mod_proxy will evolve in lighty 1.5.x, unification of the backend-plugin, .,. Well, perhaps it will be a bit earlier than 1.5.0 Over the last week and especially at this weekend I make big steps into the right direction: * a string HTTP-response parser based on lemon used by all backend plugins (FastCGI, CGI, SCGI, Proxy) * all backends use a sliding window to send data. The data-stream in chunked and as soon as a chunk is finished it is freed or reused. * the network-code is only implemented once But more important is the work on mod_proxy_core with this feature-set: * Unified core for all backends * failover, balancers, config, streaming, ... are shared * several protocols for FastCGI, CGI, SCGI and HTTP * Keep-Alive for FastCGI and HTTP * HTTP/1.1 (incl. chunked encoding to the backend) * queueing of connections in the plugin (instead of using the kernel for it) * HTTP over SSL to the backends * Host-Selection by hostname (auto-loadbalancing for multi-homed hosts) * Request/Response rewrite in the proxy-module before they are sent to the backends **What is working up to now ?** Up to now I can use RR-balancing via HTTP/1.1 with keep-alive and chunked-encoding. As testbase I used http://cnn.com/ and http://www.stern.de/ for the RR-testing and http://php.net/ to test chunked encoding. All of them are contacted via HTTP/1.1 and use Keep-Alive. I only specified the hostname, lighty resolved the hostname at startup and added all IPs to the LB-pool. .oO( Hey, it would be easy to add and remove IPs from this pool at runtime ) It was good to kill some old code on the way. The fd-event handling got a cleanup and more flexible in the handling. the old backend-plugins got simplified as the share more code, ... over all good weekend so far. **What is missing ?** Failover handling and queueing is planned for tomorrow, process-spawning will be unified a bit later. mod_proxy_core will be part of 1.4.12 next to the old, well-known plugins for FastCGI, SCGI, CGI and HTTP. When the code for mod_proxy_core is commited I advise everyone to take a look at the code for it. It is very clean and well-documented and should be easy to read. ... if you know C. :)

Please note that we won't accept comments for posts older than 3 months! Also please use our bug tracker to report bugs, and our irc channel #lighttpd@libera to chat.

« X-Sendfile mod_proxy_core commited to svn »