(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 –
close, respectively – are bound
together in a
<server-impl> object. Procedures in this module take a
<server-impl> object, if needed.
<server-impl> may also be looked up by name. If you pass the
http symbol to
run-server, Guile looks for a variable
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:
openhook is called, to open the server.
opentakes 0 or more arguments, depending on the backend, and returns an opaque server socket object, or signals an error.
readhook is called, to read a request from a new client. The
readhook 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
(web request). The body should be a string or a bytevector, or
#fif there is no body.
If the read failed, the
read hook may return #f for the client
socket, request, and body.
(web response), and the response body as a string, bytevector, or
#fif 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.
writehook is called with three arguments: the client socket, the response, and the body. The
writehook returns no values.
closehook is called on the server socket.
A user may define a server implementation with the following form:
<server-impl>object with the hooks open, read, write, and close, and bind it to the symbol name in the current module.
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
)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
(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.
Open a server for the given implementation. Returns one value, the new server object. The implementation's
openprocedure is applied to open-params, which should be a list.
Read a new client from server, by applying the implementation's
readprocedure 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
#ffor all three values.
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.
"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-typeheader, 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.
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.
Release resources allocated by a previous invocation of
Given the procedures above, it is a small matter to make a web server:
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.
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-responsebefore 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.