The way the Web server currently finds scripts to run is a local hack. The five cent summary is that the file .../foo.doit contains the program run to handle retrievals on .../foo (and is passed any parameters which came in with the request --- see below). I've written up some documentation, which you should consult if you want to know the details. (The standard, out-of-the-box approach requires scripts to be kept in separate directories from other sorts of files).
Any parameters which came in with a retrieval request (e.g., the choices the user made in filling out a form) must of course be passed to the script; this is done by setting Unix environment variables. There is actually a standard for which variables are set to what, known as the Common Gateway Interface, which our (lightly hacked NCSA) daemon supports; the CGI documentation is the place to consult if you want to know details. See also a small library of Perl routines I've thrown together to handle some of the monkey work.
One final note --- these programs are forked off on the fly to run on mini-wheats, and need to complete quickly, so Common Lisp is (at the present state of the art) not an option, barring heroic measures like some form of remote procedure call to a Lisp process running elsewhere. However, if you're going that far, you might as well have the client talk to the Lisp process directly and eliminate the middleman --- HTTP has a lot of frills which you can ignore, and the basics are real easy. (It's entirely tolerable at the state of the art to accept only GET requests, ignore the client's Accept: headers, and return boilerplate headers of your own, just so long as the Content-type matches the data --- you don't have to worry about generating correct Methods, or any of that stuff, because the clients aren't really using that information. Yet).