Homework 4: Multithreaded Web Server

Part A: Read Through Our Code

Our web server is a fairly straightforward multithreaded application. Every time a client connects to the server, the server dispatches a thread to handle all interactions with that client. Threads do not interact with each other at all, which greatly simplifies the design of the server.

The figure above shows the high-level architecture of the server. There is a main class called HttpServer that uses a ServerSocket class to create a listening socket, and then sits in a loop waiting to accept new connections from clients. For each new connection that the HttpServer receives, it dispatches a thread from a ThreadPool class to handle the connection. The dispatched thread springs to life in a function called HttpServer_ThrFn() within the HttpServer.cc file.

The HttpServer_ThrFn() function handles reading requests from one client. For each request that the client sends, the HttpServer_ThrFn() invokes GetNextRequest() on the HttpConnection object to read in the next request and parse it.

To read a request, the GetNextRequest() method invokes WrappedRead() some number of times until it spots the end of the request. To parse a request, the method invokes the ParseRequest() method (also within HttpConnection). At this point, HttpServer_ThrFn() has a fully parsed HttpRequest object (defined in HttpRequest.h).

The next job of HttpServer_ThrFn() is to process the request. To do this, it invokes the ProcessRequest() function, which looks at the request URI to determine if this is a request for a static file, or if it is a request associated with the search functionality. Depending on what it discovers, it either invokes ProcessFileRequest() or ProcessQueryRequest().

Once those functions return an HttpResponse, the HttpServer_ThrFn() invokes the WriteResponse() method on the HttpConnection object to write the response back to the client.

Our web server isn't too complicated, but there is a fair amount of plumbing to get set up. In this part of the assignment, we want you to read through a bunch of lower-level code that we've provided for you. You need to understand how this code works to finish our web server implementation, but we won't have you modify this plumbing.

Part A Instructions

1. Change to a directory with your local copy of your CSE 333 GitLab repository, which has your hw1/, hw2/, hw3/, and projdocs/ directories in it. Use git pull to retrieve the new hw4/ folder with the starter code for this assignment. You will need the hw1/, hw2/, and hw3/ directories in the same folder as your new hw4/ folder since hw4 links to files in those previous directories. By default, the HW4 Makefile builds and links your HW1, HW2, and HW3 libraries. To use the provided solution libraries instead, set USE_SOLUTION_BINARIES = true near the top of the Makefile.
2. Run make to compile the HW4 binaries. One of them is the usual unit test binary called test_suite. Run it to discover failing unit tests that you'll need to fix. The second binary is the web server itself: http333d. Try running it to see its command line arguments. When you're ready to run it for real, you can use a command like:

   $ ./http333d 5555 ../projdocs unit_test_indices/*

   (You might need to pick a different port than 5555 if someone else is using that port on the same machine as you.)
3. Run the server in solution_binaries/ using a similar command line:

   $ ./solution_binaries/http333d 5555 ../projdocs unit_test_indices/*

   Use a web browser to explore what the server should look like when it is finished:
   1. If you are running the code on a lab computer or the CSE Home VM: Launch Firefox or Chrome on that machine, visit http://localhost:5555/, and try issuing some searches. As well, visit http://localhost:5555/static/bikeapalooza_2011/Bikeapalooza.html and click around. This is what your finished web server will be capable of.
   2. If you are running the code on attu over an SSH connection: Follow the same steps as above, but navigate to the address for the instance of attu your code is running on. For example, if you are running your code on attu4, you would visit the following addresses: http://attu4.cs.washington.edu:5555/ and http://attu4.cs.washington.edu:5555/static/bikeapalooza_2011/Bikeapalooza.html
4. When you are done with the http333d server, shut it down gracefully using /quitquitquit (e.g., http://attu4.cs.washington.edu:5555/quitquitquit). Use this method whenever you run the server under Valgrind so it can finalize its heap-checking statistics.

   If you're not using Valgrind to collect statistics, another way to shut down the server is to open another terminal window on the same machine that is running the server and run the command kill pid where pid is the server process id. Use the ps -u command on the same machine (attu or local VM) to find that process id. You also can shut down the server by typing control-C in the window where it is running, but this abrupt stop isn't as graceful and will definitely make it hard for Valgrind to report accurate statistics (if you want them).

5. Read through ThreadPool.h and ThreadPool.cc. You don't need to implement anything in either, but several pieces of the project rely on this code. The header file is well-documented, so it ought to be clear how it's used. (There's also a unit test file that you can peek at.)
6. Read through HttpUtils.h and HttpUtils.cc. This class defines a number of utility functions that the rest of HW4 uses. You will have to implement some of these utilities. Make sure that you understand what each of them does, and why.
7. Finally, read through HttpRequest.h and HttpResponse.h. These files define the HttpRequest and HttpResponse classes, which represent a parsed HTTP request and response, respectively.

Part A is complete when HW4 builds, you can run the supplied server and visit both its search and static-file pages, and you understand the roles of the provided thread pool, HTTP utilities, request, and response classes.

It's time to start coding in Part B.

Part B: Basic Web Server

You are now going to finish a basic implementation of the http333d web server. You will need to implement some of the event handling routines at different layers of abstraction in the web server, culminating with generating HTTP and HTML to send to the client.

Part B Instructions

1. Take a look at ServerSocket.h. Implement BindAndListen() and Accept() in ServerSocket.cc. Your implementation must handle both IPv4 and IPv6 clients. This stage is complete when the following test passes:

   $ ./test_suite --gtest_filter=Test_ServerSocket.TestServerSocketBasic

2. Read through FileReader.h and FileReader.cc. Implement FileReader::ReadFile(), including its failure cases and support for binary data. This stage is complete when the following test passes:

   $ ./test_suite --gtest_filter=Test_FileReader.TestFileReaderBasic

3. Read through HttpConnection.h and HttpConnection.cc. First implement GetNextRequest(). It must handle partial reads and preserve bytes belonging to a subsequent request.
4. Implement ParseRequest() in HttpConnection.cc. This stage is complete when both HttpConnection tests pass:

   $ ./test_suite --gtest_filter=Test_HttpConnection.*

5. Read through HttpUtils.h and HttpUtils.cc. Implement IsPathSafe() and EscapeHtml(). This stage is complete when the relevant utility tests pass:

   $ ./test_suite --gtest_filter='Test_HttpUtils.TestHttpUtilsIsPathSafe*:Test_HttpUtils.TestEscapeHtml'

6. Implement GetPortAndPath() in http333d.cc. Verify that valid arguments start the server and that malformed ports, unreadable static directories, unreadable index files, and missing index arguments are rejected.
7. Read through HttpServer.h and HttpServer.cc, then implement HttpServer_ThrFn(). Verify that one client can send multiple requests on a connection, that responses are written, and that /quitquitquit shuts down the server gracefully.
8. Implement ProcessFileRequest() and ProcessQueryRequest() in HttpServer.cc. Exercise both web search and static file serving in a browser. You'll probably need to look at the source of pages that our solution binary serves and emulate that HTML to get the same "look and feel" to your server as ours. If you wish, you can change the appearance of the front page ("dark mode", different graphics, etc.) but you should not change or add to the functionality of the server beyond the appearance now. If you want to do more, see the Bonus section below. This stage is complete when searches return useful results, links open the indexed files under /static/, static text and binary files load with appropriate content types, and the full test_suite passes.

At this point, your web server should run correctly, and everything should compile with no warnings. Try running your web server and connecting to it from a browser as described above. Also try running the test_suite under valgrind to make sure there are no memory issues. Finally, launch the web server under Valgrind to make sure there are no issues or leaks; after the web server has launched, exercise it by issuing a few queries, then shut it down with /quitquitquit so Valgrind can finalize its report. (The supplied code does have some leaks, but your code should not make things significantly worse.)

Part C: Fix Security Vulnerabilities

Now that the basic web server works, you will discover that your web server (probably) has two security vulnerabilities. We are going to point these out to you, and you will repair them.

Part C Instructions

It's likely at this point that your implementation has two security flaws. (However, please note: it is possible that the way you implemented things above means you have already dealt with these flaws). You may find that some of the functions defined in HttpUtils.cc will be very helpful in fixing these security flaws in your web server.

• The first is called a "cross-site scripting" flaw. See this for background if you're curious: http://en.wikipedia.org/wiki/Cross-site_scripting

  Try typing the following query into our example web server, and into your web server, and compare the two. (Note: do this with Firefox or Safari; it turns out that Chrome will attempt to help out web servers by preventing this attack from the client-side!)

  hello <script>alert("Boo!");</script>

  Your browser will pop up a dialog box saying "Boo!" when you use your flawed server. To fix this flaw, you need to "escape" certain types of untrusted input from the client before you relay it to output. We've provided you with an escape function in HttpUtils that detects input which requires escaping and performs any necessary replacement, and you should implement it.

• Use nc to connect to your web server, and manually send a request for the following URL. (Browsers are smart enough to help defend against this attack, so you can't just type it into the URL bar, but nothing prevents attackers from directly connecting to your server with a program of their own!)

  /static/../hw4/http333d.cc

  This second flaw is called a directory traversal attack. Instead of trusting the file pathname provided by a client, you need to normalize the path and verify that it names a file within your document subdirectory tree (which would be ../projdocs/ if the example command shown in part A was used to start the server). If the file path names something outside of that subdirectory, you should return an error message instead of the file contents. We've provided you with a function in HttpUtils.h to help you test to see if a path is safe or not.

Part C is complete when the following tests pass, the script query is displayed as text rather than executed, and a traversal request does not return a file outside the static document directory:

$ ./test_suite --gtest_filter='Test_HttpUtils.TestHttpUtilsIsPathSafe*:Test_HttpUtils.TestEscapeHtml'

Fix these two security flaws, assuming they do in fact exist in your server. As a point of reference, in solution_binaries/, we've provided a version of our web server that has both of these flaws in place (http333d_withflaws). Feel free to try it out, but DO NOT leave this server running, as it will potentially expose all of your files to anybody that connects to it. (Also, do not leave your http333d server running at least until after you've patched these vulnerabilities for the same reason.)

Congrats, you're done with the CSE 333 project sequence!!

Bonus Tasks

Before starting bonus work, submit the required assignment using the hw4-submit tag as described in the Submission section. When the bonus work is complete, commit and push it, then create and push an hw4-bonus tag. We grade bonus work only when that tag is present.

Also, if you do any of the bonus parts of the project, you must add a readme-hw4-bonus.md text file to your hw4/ directory and include this in the files you push to your GitLab repository. This file should contain a brief description of the additions you have done and describe how to use them. This should be brief: a few sentences or a couple of paragraphs should probably be sufficient.

1. The first bonus task is to perform a performance analysis of your web server implementation, determining what throughput your server can handle (measured both in requests per second and bytes per second), what latency clients experience (measured in seconds per request), and what the performance bottleneck is. You might want to look at the httperf tool for Linux to generate synthetic load.

   You should conduct this performance analysis for a few different usage scenarios; e.g., you could vary the size of the web page you request, and see its impact on the number of pages per second your server can deliver. If you choose to do this bonus task, please include a PDF file in your submission containing relevant performance graphs and analysis.

2. The second bonus task is to figure out some interesting feature to add to your web server, and implement it! As one idea, find the implementation of a "chat bot", such as Eliza, and add it to your web server. As another idea, implement logging functionality; every time your server serves content, write out some record with a timestamp to a log file; make the log file available through the web server itself. As a third idea, change the results page to show context from matching documents, similar to how Google shows excerpts from matching pages; specifically, make it so that each result in the result list shows:

   x words + <bold>hit word</bold> + y words

   for one or more of the query words that hit.

   This part of the assignment is deliberately open-ended, with much less structure than earlier parts. The (small) amount of extra credit granted will depend on how interesting your extension is and how well it is implemented.