Next: , Previous: Responses, Up: Web

7.3.6 Web Server

(web server) is a generic web server interface, along with a main loop implementation for web servers controlled by Guile. 

     (use-modules (web server))

The lowest layer is the <server-impl> object, which defines a set of hooks to open a server, read a request from a client, write a response to a client, and close a server. These hooks – open, read, write, and close, respectively – are bound together in a <server-impl> object. Procedures in this module take a <server-impl> object, if needed.

A <server-impl> may also be looked up by name. If you pass the http symbol to run-server, Guile looks for a variable named http in the (web server http) module, which should be bound to a <server-impl> object. Such a binding is made by instantiation of the define-server-impl syntax. In this way the run-server loop can automatically load other backends if available.

The life cycle of a server goes as follows:

  1. The open hook is called, to open the server. open takes 0 or more arguments, depending on the backend, and returns an opaque server socket object, or signals an error.
  2. The read hook is called, to read a request from a new client. The read hook takes one argument, the server socket. It should return three values: an opaque client socket, the request, and the request body. The request should be a <request> object, from (web request). The body should be a string or a bytevector, or #f if there is no body.

    If the read failed, the read hook may return #f for the client socket, request, and body.

  3. A user-provided handler procedure is called, with the request and body as its arguments. The handler should return two values: the response, as a <response> record from (web response), and the response body as a string, bytevector, or #f if not present. We also allow the reponse to be simply an alist of headers, in which case a default response object is constructed with those headers.
  4. The write hook is called with three arguments: the client socket, the response, and the body. The write hook returns no values.
  5. At this point the request handling is complete. For a loop, we loop back and try to read a new request.
  6. If the user interrupts the loop, the close hook is called on the server socket.

A user may define a server implementation with the following form:

— Function: define-server-impl name open read write close

Make a <server-impl> object with the hooks open, read, write, and close, and bind it to the symbol name in the current module.

— Function: lookup-server-impl impl

Look up a server implementation. If impl is a server implementation already, it is returned directly. If it is a symbol, the binding named impl in the (web server impl) module is looked up. Otherwise an error is signaled.

Currently a server implementation is a somewhat opaque type, useful only for passing to other procedures in this module, like read-client.

The (web server) module defines a number of routines that use <server-impl> objects to implement parts of a web server. Given that we don't expose the accessors for the various fields of a <server-impl>, indeed these routines are the only procedures with any access to the impl objects.

— Function: open-server impl open-params

Open a server for the given implementation. Returns one value, the new server object. The implementation's open procedure is applied to open-params, which should be a list.

— Function: read-client impl server

Read a new client from server, by applying the implementation's read procedure to the server. If successful, returns three values: an object corresponding to the client, a request object, and the request body. If any exception occurs, returns #f for all three values.

— Function: handle-request handler request body state

Handle a given request, returning the response and body.

The response and response body are produced by calling the given handler with request and body as arguments.

The elements of state are also passed to handler as arguments, and may be returned as additional values. The new state, collected from the handler's return values, is then returned as a list. The idea is that a server loop receives a handler from the user, along with whatever state values the user is interested in, allowing the user's handler to explicitly manage its state.

— Function: sanitize-response request response body

"Sanitize" the given response and body, making them appropriate for the given request.

As a convenience to web handler authors, response may be given as an alist of headers, in which case it is used to construct a default response. Ensures that the response version corresponds to the request version. If body is a string, encodes the string to a bytevector, in an encoding appropriate for response. Adds a content-length and content-type header, as necessary.

If body is a procedure, it is called with a port as an argument, and the output collected as a bytevector. In the future we might try to instead use a compressing, chunk-encoded port, and call this procedure later, in the write-client procedure. Authors are advised not to rely on the procedure being called at any particular time.

— Function: write-client impl server client response body

Write an HTTP response and body to client. If the server and client support persistent connections, it is the implementation's responsibility to keep track of the client thereafter, presumably by attaching it to the server argument somehow.

— Function: close-server impl server

Release resources allocated by a previous invocation of open-server.

Given the procedures above, it is a small matter to make a web server:

— Function: serve-one-client handler impl server state

Read one request from server, call handler on the request and body, and write the response to the client. Returns the new state produced by the handler procedure.

— Function: run-server handler [impl] [open-params] . state

Run Guile's built-in web server.

handler should be a procedure that takes two or more arguments, the HTTP request and request body, and returns two or more values, the response and response body.

For example, here is a simple "Hello, World!" server: 

           (define (handler request body)
             (values '((content-type . ("text/plain")))
                     "Hello, World!"))
           (run-server handler)

The response and body will be run through sanitize-response before sending back to the client.

Additional arguments to handler are taken from state. Additional return values are accumulated into a new state, which will be used for subsequent requests. In this way a handler can explicitly manage its state.

The default server implementation is http, which accepts open-params like (#:port 8081), among others. See "Web Server" in the manual, for more information.