HTTP Design Exercise

Lecture Notes for CS 190
Winter 2020
John Ousterhout

  • HTTP (HyperText Transfer Protocol): request-response protocol, sent using TCP/IP sockets.
    • A client sends a request message to a server, and the server returns a response message.
    • Initially designed for fetching Web pages (browser is client), but now used for many other purposes
  • Each request described with a URL that specifies an operation and parameters, such as:
    Fields of URL:
    • Scheme (http:): identifies protocol used to fetch the content.
      • http: is the most common scheme and is the only one used in this class.
    • Host name (// or //localhost): name of the machine running the desired server.
    • Server's port number (8080): allows multiple servers to run on the same machine. Normal Web servers usually run on port 80 (the default).
    • Hierarchical portion (/friendships/create): identifies a particular request, such as create a new friendship.
    • Query info (?my_id=100&user_id=200): provides parameters for the request
    • URL encoding:
      • If a query value contains any character other than A-Z, a-z, 0-9, or any of -_.~ it must be represented as %xx, where xx is the hexadecimal value of the character.
        • " " becomes %20
        • "&" becomes %26, etc.
        • Example:
        • When extracting information from URLs, you must reverse the escaping.
  • Sample request (see slide):
    • First line contains method, URL (hierarchical portion and query), version number
      • GET method: read information from server. Should have no side effects.
      • POST method: uploads data from the browser to the server (typically form data), returns information from the server. Likely to have side effects.
      • There are several other methods defined besides these two.
    • Headers: name-value pairs providing various information that may be useful to the server.
    • A request can also contain data following the headers
      • GET method doesn't have any data
      • POST method may include additional parameters in body, in the same format as in URLs (my_id=100&user_id=200)
  • Sample response (see slide):
    • First line contains protocol version number, numerical status code, textual explanation.
    • Headers have same general format as for requests
    • Blank line separates headers from response data.
    • Response body is in JSON format in this example.
  • Divide into groups, design APIs for a general-purpose Http class (and other supporting classes, if needed)
    • Http class should make it easy to write a server that handles HTTP requests:
      • Implements the HTTP protocol
      • Provides access to information in requests
      • Helps with formatting responses
      • Goal: hide as many details as possible, make it easy to write servers.
      • Think about what will be common across all servers, what will be different for each server.
    • Must handle incorrectly formatted requests in a reasonable way (i.e., clients may be bogus).
    • Can assume that calling code (in the server) is correct.
  • What to produce:
    • Short list of what information is hidden in the Http class, what is visible to callers
    • APIs for public methods
      • Be sure to think about exceptions
    • Don't write code for method bodies