Interesting … at least now we know.

I hear ya about the lack of documentation, but I’m hopefull - Lighty is a relatively young project, but it’s sponsored by a serious vendor and is quickly gaining adoption, so better documentation can’t be that far away.

Within the same:

$HTTP["host"] == "blah" {
}

block, if you want to map urls to more than one separate fastcgi instance, the resulting configuration is not explained by the documentation and is fragile. Take the following working config snippet:

$HTTP["host"] == "hikij.wellquite.org" {
    server.document-root = "/home/matthew/hikijInstall/web/"

    $HTTP["url"] == "/Wiki.hs" {
        fastcgi.server = (
            "/Wiki.hs" =>
              ((
                "bin-path" => "/home/matthew/hikijInstall/fcgi/Wiki.fcgi",
                "socket" => "/tmp/hikij.fcgi.socket",
                "check-local" => "disable",
                "min-procs" => 1,
                "max-procs" => 1,
              ))
        )
    }

    $HTTP["url"] == "/private/Wiki.hs" {
        fastcgi.server = (
            "/private/Wiki.hs" =>
              ((
                "bin-path" => "/home/matthew/hikijInstall/fcgi/Wiki-toa-mft-ms.fcgi",
                "socket" => "/tmp/hikij-toa-mft-ms.fcgi.socket",
                "check-local" => "disable",
                "min-procs" => 1,
                "max-procs" => 1,
              ))
        )
    }
}

Now if you look at the documentation there is absolutely no way you’d believe that was necessary. The closest from the docs is probably:

fastcgi.server = ( ".php" =>
  (( "host" => "127.0.0.1",
     "port" => 1026,
     "bin-path" => "/usr/local/bin/php"
  )),
  ".php4" =>
  (( "host" => "127.0.0.1",
     "port" => 1026
  ))
)

Which, you might think, as it maps different extensions to different destinations, might be a suitable template. You would also, from that snipped, notice that “php” comes first and “php4″ second, so clearly in converting the extension to a regexp, it’s putting a $ at the end. In prefix form you might therefore expect that it puts a ^ at the start. It turns out that with enough thought, this snippet can be used as a template. For example:

    fastcgi.server = (
        "/private/Wiki.hs" =>
          ((
            "bin-path" => "/home/matthew/hikijInstall/fcgi/Wiki-toa-mft-ms.fcgi",
            "socket" => "/tmp/hikij-toa-mft-ms.fcgi.socket",
            "check-local" => "disable",
            "min-procs" => 1,
            "max-procs" => 1,
          )),

        "/Wiki.hs" =>
          ((
            "bin-path" => "/home/matthew/hikijInstall/fcgi/Wiki.fcgi",
            "socket" => "/tmp/hikij.fcgi.socket",
            "check-local" => "disable",
            "min-procs" => 1,
            "max-procs" => 1,
          ))
    )

works fine. But reverse the order of the two stanzas and you’ll only ever hit the first. The problem is that extension in the documentation is nicely converted into a regexp with a $ at the end, anchoring it. But with the prefix form (i.e. starting it with a ‘/’), there is no ^ prefixed so you get unexpected matching going on. This would be ok, if it was documented suitably. The fact that their trac wiki contains endless wrong links and the documentation is poor and often out of date only emphasises how much of a mess apache is in given the popularity of lighttpd. From their wiki home page try actually finding the fastcgi documentation…

@matthias

The libapache2-mod-fastcgi package is non-free and does not exist for 64-bit linux. Thus should be discounted forever more.

running multiple fastcgis within the same host is one of those endless “trial and error”

Do you mean ‘running more than one FastCGI application on the same host’ or ‘running multiple instances of a FastCGI application on the same host’? If the former, that’s quite serious - care to elaborate? Otherwise, why would I care?

Apache2’s FastCGI support isn’t very good. One problem I’ve had with it is that it doesn’t report itself to be what it is, so applications that take advantage of a middleware layer must explicitly be told to behave as a FastCGI server (and can’t guess it for themselves). I heard other complaints about the correctness and quality of mod-fastcgi (but nothing I ran into myself).

FastCGI … Apache2 doesn’t really have any good solution

Can you elaborate? All I had to do on my debian system was to install the libapache2-mod-fastcgi package and make some minor tweaks to the apache config.

Also, the documentation is pretty terrible: apache has much better documentation which is also much closer to being complete than lighttpd’s. The reverse http proxy in lighttpd is particularly awful, only supporting http 1.0 at the last check.

Having said all that, I do use lighttpd because it’s lighter than apache and under 64-bit linux is pretty much the only choice for unencumbered fastcgi. Just for the record, the excellant “Pound” reverse http proxy is the best solution to that limitation of lighty, plus it can do SSL termination which is very useful.