Custom asynchronous HTTP server for the Deal project.
Minimal, asynchronous, native Common Lisp web server
The goals of
:house are to be
- Minimal, but complete for the purposes of web application development
- Fully native
Performance is not on this list. This is the server/client framework you run if you never want to see an
ffi-binding error on any platform where you're able to run
sbcl. If you need high-throughput, take a look at
woo. If you need a thread-per-request model, look into
hunchentoot. If you need a file server, go set up
House has undergone a major overhaul. This should simplify a bunch of things.
- If you haven't already done so, install
- Hop into your lisp and run
(define-handler (hello-world :content-type "text/plain") () "Hello world!") (define-handler (hello-you/<name>=>>string) () (format nil "Hello there, ~a!" name)) (house:start 4040)
You should then be able to hop over to a browser and visit
http://localhost:4040/hello-world to see the plaintext
"Hello world!" response, or
http:localhost:4040/hello-you/James to see the plaintext
"Hello there, James!" (this may or may not make sense to do, depending on whether your name is James).
Threaded quick start
:house is single-threaded, using
house:start directly as above will monopolize your REPL. You might not care about that in certain circumstances, or perhaps your deployment environment can't afford the extra thread. If you do and it can, you should start
:house in a separate thread to retain your ability to evaluate things against the running system. You can do that the usual way:
(defparameter *server* (bordeaux-threads:make-thread (lambda () (house:start 4040))))
House is not a file server. Static file serving capability is provided for ease of testing, and maybe for very small-scale deployment. If you're going to be taking any significant traffic, get a reverse proxy going with something like
You can define a static file handler with
It'll handle individual files by serving them, and it'll handle directories by serving all contained files recursively.
You can re-direct to a different handler by using the
redirect! function inside of a
(define-handler (name) () (redirect! "/static/name.html" :permanent? t))
"/name" will now instead serve a
301 Moved Permanently response with a target of
"/static/name.html" (if you leave out
:permanent? t, it'll be a
307 Temporary Redirect instead). House isn't optimized for redirecting, either from the performance or the notation perspective. If you're going to be re-directing any significant number of pages, consider having your reverse proxy handling that too.
Using the type annotations
You can specify desired argument types for your handlers. For example:
(define-handler (handler) ((foo >>json) (bar >>integer) (baz (>>list #'>>keyword))) ...)
You can then use
bar as an integer,
foo as a parsed JSON s-expression and
baz as a parsed
keywords in the body of that handler. The built-in types are
>>list. The last one is a higher-order function; it expects to output a sequence of the given type.
Type annotations are just named functions. You can define your own by defining a function of
String -> a that parses a string into your desired type and possibly throws an
error of some sort on failure. If you need a more specific type, you can use
defun. For example:
(defun >>game (param) (let ((g (gethash param *game-table*))) (assert (typep g 'game)) g))
Once that's done, you can annotate parameters with the
(define-handler (handler) ((foo >>game) ...) ...)
foo will then be looked up in
asserted to be of type
'game before the handler body is evaluated.
All this is entirely optional. If you don't care about it, just pass un-annotated arguments to your handlers, and they'll do exactly what you'd expect. You'll then be able to handle the type-conversion/assertions entirely manually.
Setting up "&rest" parameters
If you define a handler with a variable name starting with
*, it will bind to the remainder of the path elements of the request. For example
(define-handler (example/<*foo>) () (format nil "~s" *foo))
(start 5000) now, then hop over to a shell, you can do
you@that:~/$ curl http://127.0.0.1:5000/example/a/b/c/d/e ("a" "b" "c" "d" "e")
Be careful with this feature;
&rest parameters shadow anything further down in the handler tree.
Takes a port-number and starts the server listening on that port.
Defines a handler. The handler body has access to the bound symbol
request in addition to its' parameters:
request: the raw
requestobject, with exported accessors
paramterscontains the raw
alistof incoming HTTP parameters
resourcecontains the raw URI, minus host and parameters
headerscontains the raw HTTP headers
alist(of particular interest is the
session-tokenscontains the raw list of session tokens associated with this request
sessioncontains the session
socketthat generated the request. In principle, you could use this to set up some sort of communication layer that isn't strict
HTTPif you like.
handler that responds with
"application/json", and automatically JSON-encodes its response.
handler that opens an
EventSource instead of closing after sending the response.
Defines a handler that very inefficiently responds with static files.
Subscribes the specified socket to the specified channel. Should only be used with stream handlers, since the socket will need to be kept open for a subscription to be relevant.
Publishes a message to all subscribers of the specified channel. At the moment, it's assumed that the message recipients are all
EventSource consumers (I'm working on a more general