CS-375: Spring 2003

Proxy HTTP Server

Your assignment is to write a proxy HTTP Server. Your server must be able to handle GET, HEAD, and POST requests. It can ignore any request that specifies any other HTTP request method. Your proxy server should support any client speaking HTTP version 1.0 or 1.1, and should work with any compatible HTTP client (browser), including Internet Explorer, Netscape Navigator, as well as a custom HTTP client written just to torture your server.

You are again allowed to work in teams of size two on this assignment. Both members must pull their weight, and at the time of project submission, I will request both a self- and partner- evaluation of contribution. Both members of the team must fully understand the required parts of the HTTP protocol.

What is and is not required:

	Your proxy server must use a port number specified as the first command line parameter (from argv[1]). Your program will be run by an automated system that requires that your server understand that it should use the port number specified on the command line!
	Your server must handle GET, HEAD and POST request methods.

	Your server can ignore any other HTTP request method (treat the request as an invalid request).
	Your server must forward HTTP request headers to the server and response headers back to the client.
	Your server does not need to be concurrent (although it's not hard and will make your proxy much more usable), as well as earn you extra credit points.
	We must not be able to kill your server simply by sending an invalid request.
	We must not be able to kill your server by stopping or killing the client (this includes pressing the STOP button in Netscape or IE).
	Your server does not need to support all the fancy features of HTTP version 1.1, we are looking for basic functionality (by fancy, I mean things like persistent connections...).

Server Output

To keep track of all requests, your server should print one line (to standard output) for each request serviced. The line should include the host name or IP address of the client, and the original request-line sent by the client (not any of headers that accompanied the request). For example, the following might be the output generated by your server if it received some requests from a client running on 219a.mathsci.denison.edu:

> proj5 1234 
219a.mathsci.denison.edu:  GET http://www.denison.edu/
219a.mathsci.denison.edu:  GET http://www.denison.edu/images/view18.jpg
219a.mathsci.denison.edu:  GET http://www.yahooligans.com/content/ images/tiger2.jpg
219a.mathsci.denison.edu:  GET http://fred.com/purchase.asp?prod=17&qty=102
219a.mathsci.denison.edu:  HEAD http://www.slashdot.org/
219a.mathsci.denison.edu:  POST http://www.fbi.gov/insecuresubmission.cgi

Note that it is not necessary to include the HTTP version number in the output (but feel free to do so if you want).

Deliverables

You should submit all source code files necessary to build your server. If you use a Makefile please include it, if not, you need to include instructions on how to build your server. Your submission must also include a file named README that includes the following:

	The names of the members of the team.
	A list of files and a 1-line description of the contents of each file.
	References to any borrowed code (the source code must also include this information).
	A description of any known problems. If you think you know how to solve the problem(s) and simply didn't have time to do so - let me know how you would plan to do it!
	Anything else you think might be useful, such as what you learned, what you had trouble with, if the project was too hard or too easy, etc.

Grading

Your server will be tested to make sure it works properly. I will use a test client that will do it's best to confuse your server by sending nonsense, incredibly long request lines, and invalid web addresses (it will also send many valid requests as well). It is acceptable that your proxy respond to any nonsense request by sending back an HTTP response code that indicates an error and closing the connection. It's not hard to send back an HTML document as well (that describes the error), but this is not required.

Your testing should include using a real browser (you can tell Netscape or IE to use your server as a proxy). If you need help getting IE or Netscape to use a proxy, ask me for help. Although using a real browser through your proxy is a great test, you need to remember that our client will send nonsense requests to your server (and it may be hard to get a real browser to do this). You can use telnet to connect to your proxy and send nonsense, or write your own test client. IMPORTANT: Make sure your proxy can handle images, don't rely soley on simple HTML documents for all your testing.

Points will be awarded as follows (partial credit is available for each item):

GET and HEAD requests work properly with polite clients	30%
POST works properly with polite clients.	20%
bad requests are handled without problems	25%
Style/readability	25%

Notes, Hints and Links

	You need to have a basic understanding of HTTP! The best places to look for information are RFC 1945 HTTP 1.0 and RFC 2616 HTTP 1.1. You may want to start with this document: Basic HTTP (1992) from w3.org. This document is an incomplete description of HTTP 1.0 (from an early proposal, I think), but it has most of the information you need for this project and is a much easier read than the RFC.
	I am not worried about whether your server can support every nitty-gritty detail of HTTP 1.1, but rather that you can write a proxy server that is usable (from a browser), robust (can deal with nonsense requests and rude clients), and the code is something that could be extended to support all the nitty-gritty details of HTTP 1.1 (I expect code that has no memory leaks, handles errors well, etc).
	If a client closes a connection prematurely, your server can receive a SIGPIPE (this happens when you call `write()` on a socket that has been closed by the other end). By default, a SIGPIPE will kill your process - so you need to handle this situation. Recall our signal handling mechanisms from earlier projects.
	If you decide to make your server concurrent (via `fork()`), you can't leave zombie processes around - they must be handled by your server.