HTTPD

Today I also worked on the HTTPD. I have extended the response- and request-classes so that the request can tell the response, that the client (i.e. the browser requesting a page) can handle compressed pages. As the evaluation, if a client understands compression is costly, I added a virtual function to the response so an implementation can inform the request, that it can't compress the contents and so it doesn't have to look into the header. Currently the error response doesn't return any data, so it obviously doesn't need to support compression. The same would be true of binary data like images, but I haven't defined a response to handle that yet, currently I can only send texts.

It has been forever that I really worked on the HTTPD, I have sometimes done some small stuff, but mostly to get it compiling again. Last weekend I managed to update my SuSE 11.1 installation to 11.2 (astoundingly the updater really works) and it finally seems to support my system well enough that I can work. The network is detected with the right speed (in 11.1 the network came up with 10Mb/s) and even my audio card works again.

I am still at the point to add compression to the HTTPD, but I first added something else. As I want to write web services in C++ I need some support to make it easier to create pages. The first addition was, to have a class which creates the HTML-header (containing the DTD, the title and so on). I will extend it later so I can also pass the location of CSS- or JS-files, that way I can write it down correctly once and don't need to remember or look up how to do it. Yes, I know I am lazy.

With that I extended my first test page to contain a bit more text. Next weekend I will try to finally add primitive support for compression.

I haven't worked on the HTTPD forever. Today I finally got it to compile again on a virtual machine. No big changes, just some missing includes needed to be added. I tried to find out, if it would be possible to develop the program in a virtual machine and it seems to work quite well. I exported the directory containing the sources with samba and could then edit the code in Visual Studio (I don't really like to use editors in VMs, they always lag a bit).

So I hope I will now finally make the changes I intended a long time ago. The thing I want to do as next thing is to add compression to the http-connection.

As you might know, I still haven't added compression to my HTTP-layer. The reasons are not only that I hadn't implemented parsing to find out, if the client can even understand it, but also because it is a very important part in my eyes and I want to do it right. I want my layer to be very fast and I have hopes I can reach that. One of the traditional speed killers in networking is excessive copying of data. So if I can save on copies, it will have a positive effect, as long as it doesn't end in making the rest more complicated.

I worked a lot on the HTTP implementation today. Now the parsing of requests should be finished. The compression still isn't implemented, because I fist had to implement the parsing of the Accept-Encoding header. This header is used by the client to inform a server if and which compression methods it supports.

I Implemented the connection header. Also fixed some issues with timeouts and sometimes the closing of a connection wasn't detected properly. And I found two big bugs in the receive buffer when testing closing when the maximum number of requests was reached.

Next will be support for compression. I already looked a bit into the zlib documentation. I used it before in my raytracer (I wrote a streambuf-implementation to store my data files as compressed XML). There is something I don't know yet, it seems as if it is possible to compress in multiple stages. This might be an interesting feature some day, as it would make it possible to create a web page where big parts are static and could be precompressed and only the variable parts would need to be compressed for each request. I don't know if that is possible, though.

Finally found some time to implement the timeouts in the HTTPD. Now I am only missing correct signaling of the connection handling stuff (basically the Connection: close when the maximum number of requests that will be served on one connection has been reached) and I would like to implement compression. That means adding the code to compress responses and the correct evaluation of the flags to know if we can send compressed data.

Then I will try to set up the benchmark I wanted to do for some time. I still have to compile a lighttpd with php support. I at least haven't seen any way to only install php without also installing Apache. As I am not really interested in Apaches behaviour I don't want to install it.

I also worked a bit on the HTTPD. On Monday I finished the addition of error responses. Whenever the program now detects something in the request that is either wrong or outside the expected range an error response is sent to the client. One example is the 414 Request-URI is too long (I never ever saw that one before either), because I decided, that no request URL in my program will ever have to be longer than 1000 characters. I basically don't see why it ever would have to be longer. Also all places which shouldn't be reached now generate a 500 Internal Error.

The next thing I did was to start working on times. I assume that the handling of requests will never take more than a second. So I don't have to query the time in every response, but only do it once after the pend finished. Also as the timestamp of a HTTP-response is only acurate to one second, it actually is only calculated once for all responses of one batch. This is only the start, the real reason to work on it is to integrate time-outs. I currently can't say "if this server doesn't drop the connection then we drop it in 120 seconds". This is important to correctly implement "Keep-Alive" connections and also if the server gets loaded it might make sense to drop slow connections only taking up ports.

This might seem counter intuitive, but if your server has to drop connections in any case, I think the ones which have the biggest impact have to go first. It is better to serve three people on a decent connection than one on a crappy connection if that is the choice you have to make. But for that I need to be able to say, that a connection is taking too much time. In case you never saw this one either, it also has a response code: 408 Request Time-Out.

Worked most of the day on the HTTPD. There were quite a lot more problems than I knew. One is especially nice, I had forgotten to set the accepted socket to be non blocking. So did the most wrong thing possible in an asynchronous design, I blocked. Well, I fixed that little problem. Then found some issues in the read buffer and completely refactored the receiving and sending logic in the HTTP-connection class.

So now I actually know that the asynchronous stuff works, I checked it again and again. Also it seems there are no more errors in the receiving stuff, so at least I make progress. I also implemented part of the error handling stuff, the program now returns an error response if something didn't work. And even closing the connection and destroying the objects work. I hope I didn't miss one, though. But I think I got them all, I will when it is a bit more advanced put it through some stress tests, then I will see if I have a memory leak.

The next three steps are to finish handling protocol errors, adding timeouts and adding correct handling of the connection settings. Currently I ignore them (and don't even send Connection: Close). Also I have to add more header stuff, I currently just store most of the headers, but I will have to treat them differently, e.g. the Connection headers, but also Cookie- and Accept-headers have to be recognised. I would like to add compressing outgoing content to the program.

I did it today, the HTTPD delivered its first HTML page. It still is nearly useless, but it at least comes along. There are a lot of things missing, but at least I slowly make progress. And seeing a browser successfully connect and render a page is quite nice.

The next thing to fix will be the already announced error handling stuff. I want the program to signal an error back to the browser. Also I have to finish the Keep-Alive-mechanism and I want to add the ability to compress pages. Then I might either try to break it by injecting errors into the connections or the performance meassurement, I haven't decided yet.

While modelling I also did some work on the HTTPD. Parsing of requests should now work. I hope I didn't create too many bugs, though. The last thing I added is a first implementation of a class to hold the request for operation. The next step will be to add code to handle the request and then implement a response class and actually send the results back to the client. Then my little program can serve its first pages.

The next thing to do is to actually implement all the error responses. I currently only put in some asserts when something unexpected happens. I will, as soon as the framework for responses is created, add error response classes and send them back to a client. It still is fun to implement this.

When I had to wait for long running operations when modelling, I have been working a bit on the HTTPD. It slowly progresses, it already is able to parse the first line of a HTTP-request. The rest of the header should be much easier, as it is all the same format. The first line looks like this:

GET / HTTP/1.1\r\n

This means, we want a page (GET), it's URI is "/" and we speak HTTP version 1.1. I only will support the methods GET, HEAD and POST. The rest of the headers are just name value pairs like:

Accept-Encoding: gzip,deflate\r\n

So if I can parse one, I can parse all of them.

What is a bit sad is, that I already have fixed the first security vulnarability, a buffer overflow.

I worked on the HTTPD. Well, what is supposed to become a HTTPD. I at least managed to get it to the point where it correctly connects itself to port 8080 and accepts connections. It immediately closes them. But that was my very first target to be reached. Quite a lot of infrastructure is in place already. E.g. the complete poll loop is already working.

The next two steps are to add some form of logging and making the existing code handle possible errors correctly. Currently I just added some asserts and that is it. I guess in a real server it is not really acceptable to just crash if something happens, like running out of sockets or similar things.

The other step to be made is to start on the HTTP-part. I will add three new classes, one will handle the HTTP-connection, one will be the HTTP-request (only GET for now) and one will be the response. Then I should be able to connect with a browser and see if I can get a web page served.

It seems as if writing a webserver isn't really so hard. I am a bit surprised, actually.

The other thing I have been doing for this project is, that I installed a fresh FreeBSD 6.1 to a test machine. It is an old box, only a Celeron 366MHz with 128MB of memory. It has a 100MBit network card. I also installed lighttpd. First thing I want to try is if lighty can saturate the network and how much power it needs. I know, the box is too weak, but it is a machine I can just reinstall when I want as I don't use it for anything else. The second thing I want to do is to install PHP 5 on it. And then write a simple PHP-page consisting only of an echo statement which creates the same page I intend to use to test lighty with. I am very curious about how much slower it is. Then I will also install xcache and do the same tests. And I want to see how my simple poll based implementation will compete with the static page.

I am really curious about the numbers.

I made the first few steps to actually implement a HTTPD based on the ideas I posted previously. The basic principle is fully asynchronous and single threaded. Not exactly simple, but I have some experience in this area. No, I haven't created a HTTPD yet, but I created a simulation system for massive parallel systems as a thesis in university. It used the same principles and was terrible to program. But it was also more than 20 times faster than a quite well made system based on threads back then.