How is the request processed? The server is capable of spawning several “worker threads” that are waiting for incoming requests. As soon as FastCGI pipe drops one more request it’s being fed into first free thread or moved to the queue. Thread itself is a black box having Request* on input and Response* on output. In case of simple CGI environment there’s only one “worker” code witch is bootstrapped with proper Request* by stdin/environment parser.
Let’s go deeper into worker thread. We now have Request object, so we’re trying to match its URL path part against regular expressions list (pretty much like Django does). As soon as we get the match it’s passed to handler class instance (known) by given SEL (also known). In fact the mapping of regular expressions list is something like (rx : [id, SEL]). Our own application handler receives Request and Match objects (you see, I’m too used to Django way of doing things ), processes it in any way and returns Response object (there might be several shortcuts like serving a ctemplate or passing a static file directly to lighttpd).
There is also a very useful thing called Intercepts. You can add an Intercept to both request chain and response chain. This stuff does some global pre-processing (or post-processing) for you.