I have been admin/arch on a so called MUD for many years, starting in the mid 90s.The MUD I started out on is written in a language called LPC, and when I left there in 2003, I started on writing a new system/game library for such a MUD. As part of this library, I wrote a webserver.

I also run a somewhat complex Apache configuration, and at first, the purpose of this small http server was to present some information from within the game and no more then that, and as such only needed a very limited subset of http. Once I got to implement and activate the http server it turned out to perform a lot better then I had expected, and on a slow evening I decided to rewrite it to become a proper, general purpose http server.

The current implementation serves static files as well as being able to retrieve content from LPC objects. It has built in session management (and supports cookies) and it even supports namebased virtual servers.

THe library, and hence the webserver run on a 'driver' called DGD. A driver is the program that provides for a virtual machine or interpreter that runs LPC code and provides the communications with the outside world to the LPC environment.

While by far not as full featured, the current http server borrows part of its design from Apache 2. It consists of a core that does http handling and can send files 'as is'. Any other way of sending a response is done by modules, which can also perform tasks like url remapping, access control, authentication and filtering of the input and output streams.

Right now the following modules exist:

• read_file : read a file and convert cr/lf if needed
• text2html : read a text file and generate simple html from it
• calllpc : calls a function in an object and optionally htmlizes the returned data
• session : handle client sessions

cgi-bin support is possible if the DGD version used supports calling external programs. In most cases cgi-bin support is not required because it is often easier and more efficient to implement a feature in LPC natively and use the calllpc module instead.

While writing this server, I found that LPC has some aspects that make life very easy for writing a http server. First of all, the excelent support for strings, mappings and arrays. Then of course there is the native support for objects.

Those things make for being able to implement much of the functionality of the Apache core in a few kilobytes of code.

Another very nice feature of this environment is its JIT support. The website at http://mud.wotf.org/ uses this to parse html templates, generate LPC code from them, and then compile and call the resulting object (and keep it in cache).

All in all a nice little project and I learned quite a few more things about http headers on the way. Still need to cleanup the code a little bit, but it looks like I wrote myself an alternative to Apache + PHP in no more then a few days time.