An Introduction to Web Development with PLT Scheme - An Intermezzo

Intermezzo

This is the third post in a series programming web applications with PLT Scheme. In part one and two the model and view of a small reddit-like application were discussed. Before turning to the control part of this application, we need to look at the basic operation of the PLT Scheme web server.

Requests and responses - the big picture

What happens when a user clicks on a link to your web-site? The browser sends a request to the web-server. The request holds among other information the protocol version and the uri (uniform resource identifier) of the requested resource. The web-server must now compute a response and send it back.

How the response is computed depends on the requested resource. In the case of static content, the response of the web-server consists of a few headers (including the mime-type of the file) and a verbatim copy of the file.

Servlets

Dynamic content is handled by servlets. A servlet is a small program that given a representation of a request computes a response, which the web-server then sends back. The standard "Hello World"-servlet reads as follows:

(module hello-world mzscheme
 (provide interface-version timeout start)
 (define interface-version 'v1)
 (define timeout +inf.0)

 ; start : request -> response
  (define (start initial-request)
   `(html (head (title "Hello World"))
          (body ([bgcolor "white"])
                (p "Coffee is bliss.")))))

A module based servlet must provide a start function, that given a request computes a response. In this case the response is XHTML represented as an X-expression. If your fancy is classical HTML as strings, you can return a list, whose first element is the mime type as a byte string, and whose second element is a list of strings (or byte strings) with the lines of the document. For more advanced purposes (such as generating incremental responses) one can return a response structure - see the documentation for details.

A little tip: If you place a call to report-errors-to-browser at the beginning of start, then the web server will catch any otherwise uncaught exceptions, generate an error page (with source location information) and send it to the client. This is considerably more convenient than constantly rumaging through log files.

Requests

Back to the request structure. A request structure holds:

• the method (get, post, ...)
• the uri of the resource
• the headers (including cookies)
• bindings (from name value pairs either from a posted form or from the query url itself)
• the host-ip (in case the same web server instance handles more than one ip)
• the client ip
• raw data from a post operations
  

The net collection contains many valuable utilities to deal with uri, headers, cookies etc. I have collected these and other utilities in a little web framework available from PLaneT. It also contains some syntax that hopefully, makes it a bit easier to write servlets. The philosophy is to let the servlet parse the request and store the information in parameters. Similarly parameters hold what will become assembled to a response, when the servlet is finished. For simple servlets, like the one above, nothing much is gained, but more advanced usage patterns like post-redirect-get become much easier to code. The last part of this series will use the framework to implement the control.

Try the PLT Web Server

The PLT Web Server is included in the DrScheme download. If you start "PLT Web Server.exe" (Windows) or "web-server-text" (unix and mac), then the static content will be served from "c:/Programs/PLT/collects/web-server/default-web-root/htdocs" and the servlets are in will be in "...default-web-root/servlets/". A few examples are included.