Re: [Chicken-users] scgi with lighttpd

[Thomas Chust]

On Wed, 4 Oct 2006, Ashish Shrestha wrote:

> Sorry for not updating. Yes, I did find that out while I was trying
> out different combinations. You mentioned documentation. I didn't find
> much in the scgi and fastcgi modules. Where is it documented?

Hello Ashish,

the lighttpd distribution tarball that I downloaded contained a doc/ 
subdirectory which in turn contained scgi.txt and fastcgi.txt. scgi.txt 
didn't say much except that one should read fastcgi.txt, but that file 
contained a bunch of relevant information about the module's 
configuration.

> Since I just started learning scheme and don't know much I am still
> going over the scgi code and trying to understand it.
>
> I am trying to modify to be able to program with 'url as interface' so 
> when I access the url http://host/photos/album1/pic1 -- I can map 
> /photos/* to a method photos and it can extract the album and picture 
> out of the url instead of doing http://host/photos?album=1&pic=1. [...]

Well, with the builtin code of the SCGI egg this is not possible in a 
straightforward manner. You could add all the possible paths to the 
resources hash table, assigning them the same handler procedure, but this 
is not exactly very clean...

But you can always modify the boilerplate code. For example you could 
override the scgi:find-resource procedure to successively strip parts of 
the path argument to scgi:find-resource and look up the result in the 
underlying hash table again until you find a matching resource. The 
handler procedure for that resource could then look at the PATH_INFO entry 
in the environment itself to decide on further processing.

Something like the following untested version of scgi:find-resource should 
do the trick:

    (define (scgi:find-resource name)
      (call/synch (scgi:resources)
        (lambda (ht)
          (let loop ((path name))
            (cond
              ((hash-table-ref/default ht path #f)
               => identity)
              ((string-index-right path #\/)
               => (lambda (i)
                    (loop (substring path 0 i))))
              (else
               #f))))))

In your resource handler you would then probably do pattern matching on a 
decomposition of (hash-table-ref env "PATH_INFO") or direct regular 
expression matching on that string.

> I think it would be useful because it allows urls like
>
> http://host/weblog/2006/jan/ -- list of posts for jan 2006
> http://host/weblog/2006/jan/15 -- post for 15 jan 2006 etc.

Personally I like request parameters better for parts of the URL that 
change dynamically -- but that's just a matter of taste most of the time.

> [...]

cu,
Thomas