Subject: Re: Review of CL web server APIs: (?) TBNL
Newsgroups: gmane.lisp.web
Date: 2003-08-19 20:55:56 GMT (5 years, 45 weeks, 4 days, 14 hours and 53 minutes ago)
FWIW, here's some info about my home-grown code I've been using for
web-based CL apps in the last ten months or so. The code uses Marc
Battyani's mod_lisp to connect to Apache and the central loop to
handle requests is based on the example code which comes with
mod_lisp. It currently only works with CMUCL and LispWorks but it
should be easy to support other CLs which work with mod_lisp.
I always wanted to release it publicly but it currently is a mess and
I haven't found the time to clean it up and document it
properly. Also, now that Kevin Rosenberg has released his cl-modlisp
package (which is comparable to parts of my code but more general and
portable), it'd probably be a good idea to factor out the "higher
level" parts and replace the lower level parts with cl-modlisp.
Anyway, I don't think this would be a good starting point for a
general API but maybe it won't hurt if I send some info:
1. Dispatching is done by a central dispatcher function which
currently just compares string prefixes based on a dispatch table
(an alist, actually) which can be modified at run time. That's
enough for my current needs but certainly not good enough for a
general API.
2. The dispatcher calls a (page) /handler/ which is a function of no
arguments. When this function is called the dispatcher has prepared
two objects for this handler - a /request/ object and a /reply/
object. These objects are bound to special variables and can be
accessed by several readers/writers.
3. When the handler is done it has to return a string which will be
the response body for this URL. But see below.
4. Request objects contain a slot for an alist of all incoming http
headers as well as other slots for the pre-parsed GET parameters
(an alist), the pre-parsed POST parameters (also an alist), the
file name of the request, the query string, the cookies sent by the
browser and the session object. See below for cookies and sessions.
5. Reply objects have four slots - COOKIES, HEADERS-OUT, CONTENT-TYPE,
and RETURN-CODE. The latter two are pre-filled with default
values. The handler function is supposed to modify the reply object
according to its needs. The final response will depend on the reply
object's contents.
6. Handlers can, at any time, throw a tag which'll immediately start
sending a response to the browser based on the reply object. For
example, there's a REDIRECT function which uses THROW to send a 302
response. The server code knows most of the usual http return codes
(302, 404, ...) and can create standard response bodies for these.
7. A /cookie/ object looks like you'd expect it to look. It has slots
for NAME, VALUE, EXPIRES, PATH, and so on. The incoming cookies are
pre-digested into cookie objects. If a handler wants to send a
cookie back to the browser it has to create a new cookie object and
add it to the COOKIES slot of the reply object.
8. The server code includes facilities for easy session
handling. Sessions are tracked via cookies and (if the browser
doesn't accept cookies) URL-rewriting - see below. The handler code
can transparently access the session after calling the function
START-SESSION somewhere in its body.
9. Each session is associated with a /session/ object which has slots
for things like the last time the user was active (requested a
page), the user agent, the remote IP, the age of the session, and
how long the session is allowed to be inactive. Sessions are
automatically garbage-collected if they have been inactive too
long. Each session has an additional slot to store arbitrary,
user-specified data with the session.
10. URL-rewriting for sessions is done automatically if the handler
body is enclosed in a corresponding macro. This includes rewriting
of A/HREF, INPUT/SRC, FORM/ACTION and various other attributes but
it assumes that the HTML output is created with CL-WHO.
11. URLs currently are just strings... :(
12. Some convenience functions for writing to the Apache log file are
included.
On a side note, I've been told by Douglas Crosher that the next
release of SCL will include a very basic http server which'll have the
same basic approach, i.e. passing request and reply objects around.
Cheers,
Edi.