600.211: Unix Systems Programming

Fall Semester 2005: September 8, 2005 - December 12, 2005

Assignment 5: Serving the Web Better

Out on: November 8, 2005
Due by: November 20, 2005 by 5:59 pm for full credit (11:59 pm for 10% off, hard deadline)
Collaboration: Teams
Grading: Packaging 10%, Style 10%, Performance 20%, Design 20%, Functionality 40%

Overview

The fifth assignment for 600.211: Unix Systems Programming picks up where the fourth one left off, adding more required features to your very own web server.

This is a team assignment, and all of you should know which team you're in (I hope). Each member of a team will receive the same score for the product you submit together. Note that some parts of this assignment are not 100% about the actual web server code. You'll see... :-)

Problem 1: Covering your Automation

First you need to improve your existing build and test process by integrating the gcov tool to measure test coverage. The goal is to have enough test cases (and ideally automated ones, hint hint!) to show that you achieve 100% line coverage for your code. While this doesn't mean that you're "done" with testing, it is simple way to make sure that you're not missing anything trivially obvious anymore.

Your second task is to modify the nightly build process to actually send a concise (!) log of the build and the automated tests to your team's mailing list. This way it should be easy to tell who broke a certain build and you can collectively go after that person; on the other hand, if everything's fine, it's reassuring to get a nice "all clear" message in the morning. :-)

Finally, if for some reason your last submission did not yet conform to the "ideals" set in Problem 2 on the previous assignment, please "round things out" in a suitable way for this assignment. As a tiny reminder: You should have everything related to the project in Subversion (except for derived files of course), you should use make or a similar tool to automate building and (to the extent possible) testing, you should use cron to regularly run a clean build and all your tests, you should have easily accessible developer documentation, maybe out of doxygen; feel free to write scripts to help with any or all of these tasks.

You must submit all your automation scripts and a short description of your automation setup when you turn in your project!

Problem 2: Complete Basic Web Server

Your main task for this assignment is to complete your basic web server by making sure that it has all of the following functionality (in some form):

You have to implement most of the HTTP/1.0 specification. If you feel like it, you can still ignore authentication (see Section 11) and the additional features from Appendix D. However, you should pay close attention to the security considerations outlined in Section 12. Please document which parts of HTTP/1.0 you do not support and why.
You must be able to handle multiple concurrent connections in some form. It is not acceptable that a broken client could tear down your server by simply connecting without sending any data. You are free to choose processes or threads for this, up to you; processes are probably easier to handle, while threads are potentially more efficient, at least on certain platforms. Please document your design for this and discuss how it compares to the obvious alternatives.
In order to do something useful with the POST request you should add some kind of Common Gateway Interface (CGI) facility; since you'll fork()/exec() something and supply certain information to it, this is an ideal please to reuse some of your shell code. It's also a potential security liability... Please document your CGI facility in sufficient detail.
If you have not done so before, turn your web server into a daemon that runs "in the background" by default; you may want to be able to switch that behavior of for debugging, but by default you should run as a daemon (see Chapter 13 of Stevens).
This is actually a series of related issues: You should take file permissions into account as you'd expect them to work; for example serve stuff that is world readable, don't serve anything else; please document your policy regarding permissions You should take care that clients can't provide "rogue" paths that would allow them to obtain files outside your web root. For URL that end in "/" you should automatically try to find appropriate index files; please document your policy for this feature. You should provide automatic index generation for paths that are accessible in your web root but don't have a suitable index file for some reason; it should be possible to switch this feature on and off for certain paths inside the web root; please document your policy for this feature.

No doubt I am forgetting something, but this should be enough for now. Feel free to check out other web servers for ideas. It might also help to check out really small web servers, for inspiration, but don't read their sources in too much detail; after all, you don't want to get into some "intellectual property" dispute, right? I recently found out about nweb and Cherokee, both of which are pretty cool. If you're security-conscious, check out Dan Bernstein's nice little publicfile server.

Deliverables

Please turn in a gzip compressed tarball of your assignment (the extension should be .tar.gz). The tarball should uncompress into a directory cs211-assignment-5-teamname with teamname replaced by your team's name (as used for the repository and the mailing list); uncompressing should not create any other files in the current directory. The tarball should contain no derived files whatsoever, but allow building all derived files with make. We expect that your Makefile handles "the usual" targets like clean and test aside from all (which is the main way we will build your program). Include a README file that briefly explains what the program does and contains any other notes you want us to check out before grading; make sure the README lists all members of your team! Include other "common" files such as INSTALL describing how to install your tool, CREDITS to pay your respects to the people whose code you're reusing, and LICENSE to describe copyright and distribution terms if you feel like it. You can look at any number of "famous" open source projects to see what kind of structure is appropriate; gif2png is a relatively small example, but you don't need everything in there. However, seeing as we're now getting close to an actual product, you should give a "real" distribution some thought.

Grading

For reference, here is a short explanation of the grading criteria. Packaging refers to the proper organization of the stuff you hand in, following the guidelines for Deliverables above. Style refers to C programming style, including things like consistent indentation, appropriate identifiers, useful comments, etc. Simple, clean, readable code is what you should be aiming for. Performance refers to how fast your program can produce the required results compared to other submissions. Design refers to proper modularization and the proper choice of algorithms and data structures; often this can be judged by asking "How hard would it be to add feature X?" and "How hard is it to replace algorithm X with algorithm Y?". Functionality refers to your program being able to do what it should according to the specification given above; if the specification is ambiguous and you had to make a certain choice, defend that choice in your README file.

If your program cannot be built you will get no points whatsoever. If your program cannot be built using make we will take off 10%. If your program cannot be build without warnings using gcc -W -Wall -O -pedantic we will take off 10% (except if you document a very good reason). If your program fails miserably even once, e.g. segfaults or runs forever, we will take off 10%.