1 / 11

The Elbert HTTP Server

This document provides a comprehensive overview of key enhancements for an HTTP server, focusing on features such as redirection (301, 302), handling timeouts, and generating status pages for various responses (200, 304, 408, 500). It discusses directory listings, non-closing connections, and ensuring proper handling of requests that do not yield a successful 2XX response. Key questions about implementation, including the behavior of different statuses and connection management, are analyzed. This resource aims to improve server architecture, aligning with RFC 2616 for robust performance.

troy-david
Download Presentation

The Elbert HTTP Server

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Elbert HTTP Server Adding redirection, timeouts, status pages, directory listings, and so much more… By: Shawn M. Jones

  2. Updated FSM

  3. Conditionals FSM

  4. The “onion” architecture

  5. Requirements Traceability Matrix From RFC 2616 Specific to the assignment

  6. Completed Work • OPTIONS MIME-Type is “message/http” • OPTIONS will have a content length of 0 • OPTIONS will support the * URI • Any get method that does not result in a 20X response code MUST have a text/html entity generated by the server (unless prohibited, like 304) • Directory listings • Support for “non-closing” connections

  7. Completed Work • 301 Moved Permanently – for “slashless directories” • 302 Found – with configuration file • Etags in Response Headers for statuses 200, 412 • 304 Not Modified • 412 Precondition Failed • If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match

  8. Work Remaining • “half-loading” pictures issue (indicating an incomplete send? Possible fix: break up entity into multiple sends.) • icons not showing for files/folders on mln-web (why?) • 408 Status (verified visually, but needs automated test) • 15 second timeout of socket connection (verified visually, but needs automated test) • Review RFC 2616 for anything missing pertaining to new headers

  9. Gold Plating if we have timeWhy? Because we like style… • “Fancy” directory listings • More fun with non-2XX status pages.

  10. Questions for Dr. Nelson • When is a closed connection expected? • As discussed in class • 400 makes sense when the URI can’t be parsed at all because something might be wrong with the incoming buffer stream after that point • 500 makes sense because we don’t know about the server state • 501 shouldn’t really need a closed connection, but the client may be expecting the server to be in a certain state after an unsupported method is used (e.g. POST) • 505 makes sense because the assumption is that the client is using the wrong HTTP version throughout the session, but what if they switch up for one request?

  11. Questions for Dr. Nelson • What data goes into the request line portion of a 408 entry of the access log? If it timed out then there may be no request line.

More Related