The requested Web page name contains the Web server name www.foo.com and the requested file on that server /mumbo.html. In this case, your proxy server should make a TCP connection to Web server www.foo.com at the default port 80 and ask for file /mumbo.html by sending the following request:

GET /mumbo.html HTTP/1.1\r\n

Connection: close\r\n\r\n

After sending a request to the “real” Web server, an HTTP response including the requested file will be received at the proxy server. The proxy server should then forward the content to the client. There are three parts in an HTTP response message: the status line, the response headers, and the entity body. The status line and response headers are terminated by an empty line (or an extra “\r\n”). In short, an HTTP response message may look like the following:

HTTP/1.1 200 OK

Date: Thu, 24 Jan 2013 15:29:52 GMT

Content-Type: text/html

Server: Joe's Web proxy server

Connection: close

... ... <content of the main.html>

The status line and most of the header fields should be forwarded to the client without

modification.

The server should be able to handle multiple simultaneous service requests in parallel. This means that the Web proxy server is multi-threaded. In the main thread, the server listens at a fixed port. When it receives a TCP connection request, it sets up a TCP connection socket and services the request in a separate thread.

The “Connection: close” setting in the above examples serves an important role --- disabling the persistent connection feature in HTTP 1.1. A persistent connection allows multiple Web requests to flow through a single TCP connection. However, the support for persistent connections is somewhat challenging and it is not required for this assignment. Note that when you test your proxy server through a standard Web browser, the “Connection: close” setting will likely not be in the HTTP request. Your proxy server can insert this setting into the request before forwarding it to the Web server so that the persistent connection is turned off.

Program Skeleton

Here we provide a hint on what the program skeleton may look like. You are, however, not required to design your program this way.

Main routine {

Parse the command line input (server port number);

Create a server socket listening on the specified port;

For each incoming client socket connection {

Spawn a worker thread to handle the connection;

Loop back to wait for/handle the next connection;

}

}

Worker thread routine {

Read the request line and header fields until two consecutive new lines;

(Note that a new line can be a single "\n" or a character pair "\r\n".)

Examine the first line (request line);

If the request method is not "GET" {

Return an error HTTP response with the status code "HTTP_BAD_METHOD";

}

Make TCP connection to the "real" Web server;

Send over an HTTP request;

Receive the server's response;

Close the TCP connection to the server;

Send the server's response back to the client;

Close the connection socket to the client.

}