Term Project
CSSE 432 – Computer Networks

Web Server Specifications

Objectives

In this project, you will:

demonstrate your understanding of application layer (HTTP) and network layer protocols.
work in teams to implement a functioning HTTP/1.1 compliant web server that supports multiple clients simultaneously.

Project teams

You will work in teams of two to four members. A repository has been created for your team. Clicking on the link for your team repository will reveal the URL for that repository. Each member of your team is advised to checkout your team repository at the start of the project. Before you edit code, documents, or other aspects of the project, you should update your local workspace, edit, update, then commit your work back to your repository. Using that cycle will minimize subversion conflicts. Remember to provide appropriate commit messages and to do svn add if you want to add new files to your repository. Of course, don't forget to commit after you add new files.

Team 01
- alvessr, murphysw, sturgedl
Team 02
- onggr, schuenjr, hansondg
Team 03
- cooperra, postcn, smithgb
Team 04
- millerc5, miskowbs, stewarzt
Team 05
- coxbc, iversoda, shomerrt, vianadcc

Project Description

Your project is to design and implement a functioning HTTP/1.1 compliant web server that supports multiple clients simultaneously. The web server should have a security component of your choice and should support persistent and stateful connections (using cookies or otherwise).

Programming Guidelines

Your web server may be written in any language (Java, Python, or C, although C is preferred). Do not use any custom socket classes or libraries except for libssl (if you are implementing SSL support).

Be sure to provide a Makefile OR bash script for building AND running your web server.

Running the server

Your web server must accept the following command line options in any arbitrary order. If an argument is left out when running the server, then the specified default values will be used.

-p port: Overrides the default port the server should run on. The default is port 8000 (note that ports under 1024 require root access to use, so we cannot use port 80 as default).
-root path: Sets the root directory of the web server. This is where the files are served from. For example, if the server is run with
```
-root ./networks/website
```
then a request for http://www.myserver.com/index.html will result in serving the file ./networks/website/index.html. If this option is not present, ./www will be used as the default root directory.
-debug: When this option is present, you may print out debugging messages to the console (stdout). When this option is not present, your program may not print any output to the console.
-s sslport: If you are implementing SSL support, your server listens for an SSL connection on the specified port. Your server should be able to listen on a normal port and on an SSL port at the same time, and handle both types of connections. The default SSL port is 8001.

A README file is provided in your project repository. Be sure to add detailed instructions on how to run and test your web server. Add notable features that you implemented in your web server.

HTTP Operations

You may refer to RFC 2616 for further information on the HTTP/1.1 specifications. You will need to support the GET, HEAD, and POST request methods. You will need to implement only the 200, 301, 400, 404, 500, and 501 error codes. Your server should also respond to the Host, User-Agent, Connection, Accept, and at least two other request headers. It should also produce appropriate response headers including but not limited to the Date, Server, Content-Length, Connection and Content-Type headers.

Persistent Connections

If an HTTP/1.1 client (web browser, telnet, client program) sends multiple requests through a single connection, the server MUST keep the connection open and send responses back in the same order as the requests. If a request includes the Connection: close header, then that request is the final one for the connection and the server should close the connection after sending the response. Also, the server should close an idle connection after some timeout period (can be anything, but yours should be 15 seconds). Your server must support these persistent connections. Please remember that a single client may issue additional requests while your server is still reading the first request. In this case, your server must read in and process all requests before closing the connection.

Multiple Connections

A web server that accepts only one connection at a time is probably impractical and definitely not very useful. As such, your server should also be written to accept multiple connections (usually from multiple hosts). It should be able to simultaneously listen for incoming connections, as well as keep reading from the connections that are already open. Note that today's web browsers may open two connections to your server (as per RFC 2068), so your server should be able to handle these multiple connections.

Stateful Connections and the Security Component

You will be responsible for choosing your own method of implementing state and security in your web server. Your design should be described in a design document. Suggestions include implementing cookies or a database to maintain state or implementing SSL or firewalls within the web server for the security component. Be sure to invest sufficient time to properly research methods of implementing state and security in your web server.

Milestones

Prototype Demonstration #1 (End of Week 7): Teams will demonstrate their server. Teams should demonstrate that their server starts with the right command line arguments, handles, GET and HEAD requests, and returns the correct error codes.
Prototype Demonstration #2 (End of Week 8): Teams will demonstrate that their server supports multiple connections.
Design Document (Start of Week 9): Teams should submit their design document in the svn folder called Documentation. The document should include:
1. The programming language that the team decided to be use.
2. The socket infrastructure provided by the language (socket/bind/listen/accept).
3. Description of your proposed implementation for stateful connections and your security component.
Prototype Demonstration #3 (End of Week 9): Teams will demonstrate that their server has a security component and supports stateful connections.
Final Demonstration and Final Report (End of Week 10): Teams will do a demonstration in class. Teams will also submit a final report to their Project folder on svn. The final report will include a final description of the server implementation and code.

Grading

Artifacts	% of Grade
Prototype Demonstration #1	10
Prototype Demonstration #2	15
Design Document	10
Prototype Demonstration #3	15
Final Demonstration	40
Final Report	10

Resources

Theis project was adapted from this Mini Web Server Assignment. A thorough description of the various components in this project and a long list of resources are available from the Mini Web Server assignment.
HTTP Made Really Easy
Various RFCs for the protocols.

Term Project CSSE 432 – Computer Networks