15-441 Project 1 -- Checkpoint 2
Checkpoint 2 is worth potentially 10 total points out of 100 towards
Project 1. The work started here, when completed, will be worth 25 total points
out of 100. To receive the points and continue working on Project 1 you must:
Useful resources:
- FAQ - FAQ from your questions. Email us (quicker), or bboard it!
- Annotated Excerpted RFC 2616 Text - This helps you interpret some RFC text and better understand the exact features you should implement
- dumper.py - Point a web browser to this Python web server and observe requests
- Static Site - Demo static website to serve with Liso
- Liso Prototype - Python web server demoing what requests from Liso should look like; not a full solution
- 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.
- Create an HTTP 1.1 parser and 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 1 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. In addition, they should be logged to a file as specified in the project documentation.
- Submission is in the form of a 'git tag checkpoint-2 xxXXxxXXxx' which must exist in your repository by Friday 9/30 (cut off is midnight).
- Final step is to upload the tag via 'git push --tags'
Refer to Recitation 2 notes (final slides) which show hints at layered API calls for your web server.
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. It should expose an API to Checkpoint 2 that also uses functions provided by Checkpoint 2. That is,
Checkpoint 2 also provides functions used by Checkpoint 1 (you are free to design differently, this is only a suggestion).
For example, Checkpoint 2 might provide an HTTP 1.1 finite state machine that interprets and parses bytes coming in on buffers from
Checkpoint 1. 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 'git tag checkpoint-2 xxXXxxXXxx' (fill in the x's with the commit you want to submit, don't forget to push!):