Begin with your repository and state of work from Checkpoint 1
Create a logging module for your project.
Handle creation of a log file as specified in the project handout.
Make API functions for formatted (up to you; we may specify this later) writing to this log file (not thread-safe).
Make an API function for gracefully closing this log file.
Expose and use this module/API within the Checkpoints instead of using stderr or stdout.
Log IP addresses and browser information/settings as coming from connected clients.
Log all errors encountered to the log file.
Enhance HTTP 1.1 parser and add a layer supporting GET, HEAD, and POST as defined in RFC 2616.
Your server should serve files out of a specific folder as specified in the project handout document.
You must read and write files from disk in this step, with full error handling (permissions, file does not exist, IO errors, etc.).
This server should build off of Checkpoint 1. We have provided some design guidelines for overall architecture below.
This server should also handle errors in a sane way. It should never completely crash (make it as robust as possible). Send proper HTTP 1.1 error codes back to the browser.
Errors should be reported to a client as HTTP 1.1 error responses.
Submission is the same as Checkpoint 1. Tag and upload your repo in a tarball to the corresponding lab on autolab by 9/22 (cut-off is midnight).
Checkpoint 2 builds on top of the foundation you built in Checkpoint 1. Try architecting these two checkpoints as 'layers' in your
design. You have the low-level select() layer from Checkpoint 1 which serves as a blackbox handling the select() system call and
associated recv() and send() calls. You must also have a HTTP 1.1 parser as part of Checkpoint 1 on top of the select() layer. In this checkpoint,
you will enhance your web server to provide a response for all input requests and support persistent connections.
Think of checkpoint 2 as a HTTP 1.1 finite state machine that interprets and parses bytes coming in on buffers from
Checkpoint 1 and responds accordingly. It might also provide special disconnect handlers as needed to cleanup state if a connection closes inside Checkpoint 1
without sending a proper HTTP 1.1 close header option. In addition, Checkpoint 1 might provide functions or a method of passing back
bytes in some buffer that Checkpoint 2 wants to be written back to the client.
Architect this however you like, you are the software
engineer here designing and building a web server based on select().
Files we expect to see in your submission:
Makefile - make sure nothing is hard coded specific to your user; should build a 'lisod' file which runs the HTTP 1.1 server
All of your source code - all .c and .h files
readme.txt - file containing a brief description of your current implementation of lisod
tests.txt - file containing a brief description of your testing methods for lisod
vulnerabilities.txt - identify at least one vulnerability in your current implementation