Web server finished

The programming adventures continue! I finished the second assignment (a web server built from scratch), which hopefully gets a pass, which would allow me to put all focus into the last assignment!

First of all, I apologize for not writing a post the week before this. I was exhibiting Flash & Crash at DreamHack Winter, and never really found the time to sit down and write a post. When I got home on the Monday, I had forgotten about it.

So yeah, the web server. Code can be found here. There were some requirements; it had to:

• Send HTTP/1.1 headers (done in sendRequestedData(), constructSendData() and constructHeader())
• Handle invalid GET requests (such as having “/../../” in the request to access files or folders outside of the server folder) (done in handleData())
• Keep connections alive by default (done in run())
• Respect the browsers’ connection header (done in handleData() and handleConnectionData())

Init() takes a port, which the server then listens to for incoming data. Was done to make it slightly easier to set up.

It feels like ghetto fixes (that is, solutions that build on assumptions, or code that might blow up in your face if something unexpected happens) are everywhere in this project. These are done since I’m either not 100% sure on how something works, or it was just the most convenient way of doing it. For example, in constructSendData(), we can assume that if a specific file is requested, it will have a dot between the name and file extension, and thus we can send that file. If the dot is not present, then default to the index.html in that folder. If we want to access an index.html in a folder containing a dot, we’re screwed unless we specifically ask for it.

Some issues I have noticed is that it sometimes doesn’t get a header from the connecting browser, for whatever reason. Since the length of the header is 0, it just ignores it and goes back to checking for new requests instead, effectively skipping that connection until the next loop, where it might have received some data. This seems to happen more frequently when connecting with Chrome instead of Firefox or IE.

There are probably tons of other exploits similar to having /../ in the request, but I’m not well versed enough in web security to address them 😀