2.1 Modifiable Files

In your solution, you must only modify the following files. Modifications of other files may break things:

• http.c
• http.h
• server.c

2.2 Webserver overview

HTTP sends messages over a socket (or, for some of our tests, other file-like objects). Messages have 3 parts:

1. A start line that explains what type and version of message it is
2. Zero or more header lines, each a key-value pair
3. Optionally, a message body (also called a payload)

A web server (which is what you’re making in this MP) needs to receive and parse HTTP messages of the various Request types and construct and sent HTTP messages of the various Response types.

We’ve split these tasks into several functions. In order of calling, they are

1. Either server.c’s main (which is complete and needs no changes from you) or a tester file establishes a connection to a client.

2. Either server.c’s client_thread (which you’ll write in part 3) or a tester file manages that connection and calls httprequest_read with the open connection as an argument.

3. http.c’s httprequest_read (which you’ll write in part 2) assembles an HTTP message from one or more packets, parses it, and stores it in an HTTPRequet structure defined in http.h by:

   1. using http.c’s httprequest_parse_headers to parse the start line and header lines; and
   2. using the parsed headers to read the message body.

   This information gets stored in the HTTPRequet structure, which you may add to if you wish. Because you may add to it, getter functions are used to access its key details rather than using direct field access, and a destructor function is used to deallocate any resources it has used.

4. server.c’s client_thread uses the parsed request message to decide what response message to send.

The details of each of these pieces (e.g. how you know that you’ve passed the end of the headers) are defined in RFC 2616.

2.3 Part 1: Parsing an HTTP request

Implement the API provided in http.{c,h}, excluding httprequest_read. The main function in this part is httprequest_parse_headers, which must populate the provided HTTPRequest *req data structure with the contents from char *buffer.

The other functions include:

• httprequest_get_action, to get the action verb (ex: GET) from the HTTP request,
• httprequest_get_path, to get the path (ex: /) from the HTTP request,
• httprequest_get_header, to get a value for a specific header (ex: Host -> localhost), and
• httprequest_destroy, to free any memory stored by an HTTPRequest struct

While working on this part:

• You can (and will have to) add to the HTTPRequest struct in http.h (possibly also creating other structs in there, too).
• You must populate the action, path, version fields in HTTPRequest while parsing the packet as part of httprequest_parse_headers.

2.4 Part 2: Reading an HTTP request from a socket

Complete httprequest_read. This function is called with a file descriptor where you must read to read the contents of the request.

• You should use your httprequest_parse_headers to parse the headers of the request.
• The Content-Length header is a special HTTP header that will help you out to read the payload of the request.

To pass some of the tests you will need to use read not recv when reading from the socket.

2.5 Part 3: Building a Web Server

We have provided a partial threaded socket-based web server in server.c. You need to finish implementing the client_thread function.

Our code has a main thread in the function main and spawns worker threads to run client_thread. The main thread is fully complete (no edits needed) and does the following:

1. Accepts a port number as a command-line argument
2. Asks the OS to let it listen for incoming messages by asking for a socket, then binding it to that port and asking the OS to listen for incoming connections
3. Repeatedly
   1. accept an incoming connection, which opens a new socket to talk over
   2. create a worker thread to speak with the client over that connection
   3. detach the worker thread, meaning ignore it’s final results and let it retire when its job is done

You will write the client_thread function in server.c:

• You must read an HTTP request from the fd (use your httprequest_read).
• You must create an HTTP response to respond to the request.
  • If the requested path is /, you should process that request as if the path is /index.html.
  • If the file does not exist in your static directory (excluding the /), you must respond with a 404 Not Found response.
  • If the file requested does exist, you will respond with a 200 OK packet and:
    • Return the contents of the file as the payload,
    • If the file name ends in .png, the Content-Type header must be set to image/png.
    • If the file name ends in .html, the Content-Type header must be set to text/html.
• You can (and probably should, to make it easier for you) close(fd) after responding to the request. This will ensure the browser opens a new socket (and you will have a new thread) when making another request. (You can continue to re-use this same socket and keep the connection alive, but this is not required.)

3.1 Memory Correctness

For full credit, your MP must run valgrind clean.

• On Windows/WSL, you can directly run valgrind with valgrind ./test.
• On macOS, you can run valgrind via a docker container.

docker build -t cs340  .

docker run -p 34000:34000 --rm -it -v "`pwd`:/mp4" cs340

cd mp4
make clean
make
make test
./test

3.2 Submission

Once you have locally passed all the tests, you will need to submit and grade your code. First commit using the standard git commands:

git add -A
git commit -m "MP submission"
git push

3.3 Grading

The initial grading is done via a manual GitHub Action. You MUST complete this step before the deadline to earn any points for the MP:

• Navigate to your repository on https://github.com/cs340-illinois.
• Click on the Action Tab
• Choose mp4 autograding
• Click the green Run Workflow button (located on the blue bar)
• Press Run Workflow
• You will trigger a GitHub Action that will complete the grading run!

3.4 Points

2/3 of points are for the autograder part of the GitHub Action

1/3 of points are for the valgrind part of the GitHub Action