Forum

Hiawatha version: 7
Operating System: FreeBSD 8.1 64-bit

Does anyone have a HOWTO on setting up Hiawatha with a C/C++ FastCGI application? I have been trying for half a day, and I am ready to tear my hair out. I have looked at the standard HOWTO documented for PHP, but it is not clear to me how much this needs to be modified for C/C++. Do I need to modify the php-fcgi.conf file, even though the app is in C/C++?

I also read this topic and tried adjusting my hiawatha.conf to match, but to no avail (I just get a 404 error with an empty document root, and an empty page when I touch index.html in the document root - at no stage does the application ever get called, though.)

This is my hiawatha.conf (with commented lines removed)

ConnectionsTotal = 150
ConnectionsPerIP = 10
SystemLogfile = /var/log/hiawatha/system.log
GarbageLogfile = /var/log/hiawatha/garbage.log


Binding {
        Port = 80
}


FastCGIserver {
        FastCGIid = QFastCGI
        ConnectTo = 127.0.0.1:2005
        SessionTimeout = 30
}


UrlToolkit {
        ToolkitID = app_toolkit
        RequestURI exists Return
        Match .* UseFastCGI QFastCGI
}


Hostname = 127.0.0.1
WebsiteRoot = /usr/local/www/hiawatha
StartFile = index.html
AccessLogfile = /var/log/hiawatha/access.log
ErrorLogfile = /var/log/hiawatha/error.log
ErrorHandler = 404:/error.cgi


VirtualHost {
        Hostname = bsd.speedport.ip
        WebsiteRoot = /var/www/app
        AccessLogfile = /var/log/hiawatha/access.log
        ErrorLogfile = /var/log/hiawatha/error.log
        TimeForCGI = 5
        UseToolkit = app_toolkit
}

I used the cgi-fcgi tool to launch my C application (named index.cpp -> index), and it is sitting behind port 2005 on my local machine (127.0.0.1). A quick check with sockstat shows this:

bsd# sockstat 
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS      
nobody   hiawatha   38597 3  tcp4   192.168.1.134:80      *:*
root     index      38083 0  tcp4   *:2005                *:*
root     index      38083 1  tcp4   *:2005                *:*
oliver   sshd       21843 3  tcp4   192.168.1.134:22      192.168.1.125:2213
oliver   sshd       21843 4  stream -> ??
root     sshd       21560 3  tcp4   192.168.1.134:22      192.168.1.125:2213
root     sshd       21560 5  stream -> ??
root     login      1041  3  dgram  -> /var/run/logpriv
smmsp    sendmail   970   3  dgram  -> /var/run/log
root     sendmail   966   3  dgram  -> /var/run/logpriv
root     sendmail   966   4  tcp4   127.0.0.1:25          *:*
root     sshd       958   3  tcp6   *:22                  *:*
root     sshd       958   4  tcp4   *:22                  *:*
root     syslogd    664   4  dgram  /var/run/log
root     syslogd    664   5  dgram  /var/run/logpriv
root     syslogd    664   6  udp6   *:514                 *:*
root     syslogd    664   7  udp4   *:514                 *:*
root     devd       527   5  stream /var/run/devd.pipe
_dhcp    dhclient   510   5  stream /var/run/devd.pipe
root     dhclient   494   5  stream /var/run/devd.pipe

I also tested this with a quick telnet to port 2005, I got disconnected after typing some text, but something is definitely going on there. The C program itself is this one:

http://www.hiawatha-webserver.org/files/fastcgi/fastcgi.c.txt

Any help would be greatly appreciated.

Don't worry and leave your hair where it is. We'll solve your problem

As you can read in the CGI and FastCGI HOWTO, there are two kinds of FastCGI applications. The pipe kinds and the socket kinds. The FastCGI example I have on my website (the one you are using) is a socket kind of FastCGI application.

The cgi-fcgi tool is a tool to use pipe FastCGI applications as socket FastCGI applications. In other words, you don't need the cgi-fcgi tool to use the example code from my website. Just compile it and run it from the prompt. If everything went well, the prompt should not return.

Thanks for the quick reply, Hugo.

I did try launching the executable directly, and a quick check with sockstat revealed it was indeed running:

bsd# sockstat | grep index
root     index      1114  3  tcp4   *:2005                *:*

A quick Telnet session also showed something was going on:

bsd# telnet 127.0.0.1 2005
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Hello

Connection closed by foreign host.
bsd#

I also got some interesting results when trying to curl and telnet to 127.0.0.1, yet using the system and domain name worked:

bsd# curl 127.0.0.1
curl: (7) couldn't connect to host
bsd#

bsd# telnet 127.0.0.1 80
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host
bsd#

bsd# curl bsd.speedport.ip
bsd#

bsd# telnet bsd.speedport.ip 80
Trying 192.168.1.134...
Connected to bsd.speedport.ip.
Escape character is '^]'.
GET / HTTP/1.1
Host: bsd.speedport.ip

HTTP/1.1 200 OK
Date: Tue, 12 Oct 2010 12:53:57 GMT
Server: Hiawatha v7.3
Connection: keep-alive
Content-Type: text/html
Last-Modified: Mon, 11 Oct 2010 13:46:10 GMT
Content-Length: 0

^C

Connection closed by foreign host.
bsd#

bsd# telnet bsd.speedport.ip 80
Trying 192.168.1.134...
Connected to bsd.speedport.ip.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 200 OK
Date: Tue, 12 Oct 2010 13:00:53 GMT
Server: Hiawatha v7.3
Connection: close
Content-Type: text/html
Last-Modified: Mon, 11 Oct 2010 12:46:27 GMT
Content-Length: 1605

(Standard Hiawatha welcome page in /usr/local/www/hiawatha is shown, rather than the empty index.html in /var/www/app).


Unfortunately, it does not seem to matter if the socket is present or not - whenever I make a request to bsd.speedport.ip (the Hiawatha host), it just returns a blank page or 404 error (depending whether or not the /var/www/app/index.html file is present). It seems to me that I still have Hiawatha misconfigured, in that it doesn't use the FCGI application - but tries to serve up the page directly from the document root whenever I visit bsd.speedport.ip.

This is just a test machine running on VMware - I'll scratch it and re-install from scratch, and document what steps I took. The one thing that did bother me about setting up FCGI is that there is not much documentation on C/C++ applications - there's lots there for PHP, but I would prefer to use C/C++.

Okay, the server setup procedure I used is as follows:

a) FreeBSD 8.1 (AMD64/x64 architecture) with minimal install, with the following additional software/features from the install DVD:

1) bash
2) curl
3) perl
4) FreeBSD Ports collection in /usr/ports

b) Disabled sendmail with the following additions to /etc/rc.conf:

sendmail_enable="NONE"
sendmail_msp_queue_enable="NO"
sendmail_outbound_enable="NO"
sendmail_submit_enable="NO"

c) Install Hiawatha...

bsd# cd /usr/ports/www/hiawatha/
bsd# make

[Selection for Hiawatha build: All, except Hiawatha CommandChannel and IPv6 support - the default included IPv6, but I unticked that item only]
[Selection for libxslt build: All, except Enable Memory Debugging - the default selection, in fact]

Lots and lots of compiling, and then installation:

bsd# make install
===>  Installing for hiawatha-7.3
===>   hiawatha-7.3 depends on executable: pkg-config - found
===>   hiawatha-7.3 depends on shared library: xml2.5 - found
===>   hiawatha-7.3 depends on shared library: xslt.2 - found
===>   Generating temporary packing list
===>  Checking if www/hiawatha already installed
test -z "/usr/local/bin" || ./install-sh -c -d "/usr/local/bin"
  install  -s -o root -g wheel -m 555 'ssi-cgi' '/usr/local/bin/ssi-cgi'
test -z "/usr/local/sbin" || ./install-sh -c -d "/usr/local/sbin"
  install  -s -o root -g wheel -m 555 'cgi-wrapper' '/usr/local/sbin/cgi-wrapper'
  install  -s -o root -g wheel -m 555 'hiawatha' '/usr/local/sbin/hiawatha'
  install  -s -o root -g wheel -m 555 'php-fcgi' '/usr/local/sbin/php-fcgi'
  install  -s -o root -g wheel -m 555 'wigwam' '/usr/local/sbin/wigwam'
test -z "/usr/local/sbin" || ./install-sh -c -d "/usr/local/sbin"
 install  -o root -g wheel -m 555 'extra/newroot' '/usr/local/sbin/newroot'
make  install-exec-hook
chmod u+s /usr/local/sbin/`echo cgi-wrapper | sed -e "s,x,x,"`
test -z "/var/log/hiawatha" || ./install-sh -c -d "/var/log/hiawatha"
test -z "/usr/local/man/man1" || ./install-sh -c -d "/usr/local/man/man1"
 install  -o root -g wheel -m 444 './doc/cgi-wrapper.1' '/usr/local/man/man1/cgi-wrapper.1'
 install  -o root -g wheel -m 444 './doc/hiawatha.1' '/usr/local/man/man1/hiawatha.1'
 install  -o root -g wheel -m 444 './doc/newroot.1' '/usr/local/man/man1/newroot.1'
 install  -o root -g wheel -m 444 './doc/php-fcgi.1' '/usr/local/man/man1/php-fcgi.1'
 install  -o root -g wheel -m 444 './doc/ssi-cgi.1' '/usr/local/man/man1/ssi-cgi.1'
 install  -o root -g wheel -m 444 './doc/wigwam.1' '/usr/local/man/man1/wigwam.1'
test -z "/usr/local/www/hiawatha" || ./install-sh -c -d "/usr/local/www/hiawatha"
 install  -o root -g wheel -m 444 'doc/index.html' '/usr/local/www/hiawatha/index.html'
make  install-data-hook
===============================================================================

The Hiawatha webserver is now installed.

Edit the configuration files in /usr/local/etc/hiawatha to suit your needs.

Add hiawatha_enable="YES" to rc.conf and start Hiawatha by running:
/usr/local/etc/rc.d/hiawatha start

===============================================================================
===> Installing rc.d startup script(s)
===>   Compressing manual pages for hiawatha-7.3
===>   Registering installation for hiawatha-7.3
===> SECURITY REPORT: 
      This port has installed the following binaries which execute with
      increased privileges.
/usr/local/sbin/cgi-wrapper

      This port has installed the following files which may act as network
      servers and may therefore pose a remote security risk to the system.
/usr/local/sbin/hiawatha

      This port has installed the following startup scripts which may cause
      these network services to be started at boot time.
/usr/local/etc/rc.d/hiawatha

      If there are vulnerabilities in these programs there may be a security
      risk to the system. FreeBSD makes no guarantee about the security of
      ports included in the Ports Collection. Please type 'make deinstall'
      to deinstall the port if this is a concern.

      For more information, and contact details about the security
      status of this software, see the following webpage: 
      http://www.hiawatha-webserver.org/

d) Set it up so that it actually runs at startup:

bsd# echo 'hiawatha_enable="YES"' >>/etc/rc.conf
bsd# cat /etc/rc.conf

# -- sysinstall generated deltas -- # Tue Oct 12 17:13:34 2010
# Created: Tue Oct 12 17:13:34 2010
# Enable network daemons for user convenience.
# Please make all changes to this file, not to /etc/defaults/rc.conf.
# This file now contains just the overrides from /etc/defaults/rc.conf.
hostname="bsd.speedport.ip"
ifconfig_em0="DHCP"
keymap="uk.iso"
sendmail_enable="NONE"
sendmail_msp_queue_enable="NO"
sendmail_outbound_enable="NO"
sendmail_submit_enable="NO"
sshd_enable="YES"
hiawatha_enable="YES"

e) Fix a minor default configuration problem with Hiawatha on FreeBSD and reboot, to make sure it works:

bsd# /usr/local/etc/rc.d/hiawatha start
Starting hiawatha.
Error creating work directory '/var/lib/hiawatha'
bsd# mkdir /var/lib
bsd# /usr/local/etc/rc.d/hiawatha start
Starting hiawatha.
bsd# init 6

f) Quick test to see if everything works as intended:

bsd# curl 127.0.0.1

(Standard welcome page for Hiawatha appears)

g) Set up FCGI:

bsd# cd /usr/ports/www/fcgi/
bsd# make
bsd# make install
===>  Installing for fcgi-devkit-2.4.0
===>   Generating temporary packing list
===>  Checking if www/fcgi already installed
Making install in libfcgi
/bin/sh ../mkinstalldirs /usr/local/lib
 /bin/sh /usr/local/bin/libtool --mode=install /usr/bin/install -c -o root -g wheel  libfcgi.la /usr/local/lib/libfcgi.la
libtool: install: /usr/bin/install -c -o root -g wheel .libs/libfcgi.so.0 /usr/local/lib/libfcgi.so.0
libtool: install: (cd /usr/local/lib && { ln -s -f libfcgi.so.0 libfcgi.so || { rm -f libfcgi.so && ln -s libfcgi.so.0 libfcgi.so; }; })
libtool: install: (cd /usr/local/lib && { ln -s -f libfcgi.so.0 libfcgi.so || { rm -f libfcgi.so && ln -s libfcgi.so.0 libfcgi.so; }; })
libtool: install: /usr/bin/install -c -o root -g wheel .libs/libfcgi.lai /usr/local/lib/libfcgi.la
libtool: install: /usr/bin/install -c -o root -g wheel .libs/libfcgi.a /usr/local/lib/libfcgi.a
libtool: install: chmod 644 /usr/local/lib/libfcgi.a
libtool: install: ranlib /usr/local/lib/libfcgi.a
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
 /bin/sh /usr/local/bin/libtool --mode=install /usr/bin/install -c -o root -g wheel  libfcgi++.la /usr/local/lib/libfcgi++.la
libtool: install: warning: relinking `libfcgi++.la'
libtool: install: (cd /usr/ports/www/fcgi/work/fcgi-2.4.0/libfcgi; /bin/sh /usr/local/bin/libtool  --mode=relink c++ -O2 -pipe -fno-strict-aliasing -o libfcgi++.la -lfcgi -rpath /usr/local/lib fcgio.lo )
libtool: relink: c++ -shared -nostdlib /usr/lib/crti.o /usr/lib/crtbeginS.o  .libs/fcgio.o   -Wl,-rpath -Wl,/usr/local/lib -L/usr/local/lib -lfcgi -L/usr/lib -lstdc++ -lm -lc -lgcc_s /usr/lib/crtendS.o /usr/lib/crtn.o    -Wl,-soname -Wl,libfcgi++.so.0 -o .libs/libfcgi++.so.0
libtool: install: /usr/bin/install -c -o root -g wheel .libs/libfcgi++.so.0T /usr/local/lib/libfcgi++.so.0
libtool: install: (cd /usr/local/lib && { ln -s -f libfcgi++.so.0 libfcgi++.so || { rm -f libfcgi++.so && ln -s libfcgi++.so.0 libfcgi++.so; }; })
libtool: install: (cd /usr/local/lib && { ln -s -f libfcgi++.so.0 libfcgi++.so || { rm -f libfcgi++.so && ln -s libfcgi++.so.0 libfcgi++.so; }; })
libtool: install: /usr/bin/install -c -o root -g wheel .libs/libfcgi++.lai /usr/local/lib/libfcgi++.la
libtool: install: /usr/bin/install -c -o root -g wheel .libs/libfcgi++.a /usr/local/lib/libfcgi++.a
libtool: install: chmod 644 /usr/local/lib/libfcgi++.a
libtool: install: ranlib /usr/local/lib/libfcgi++.a
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
Making install in cgi-fcgi
/bin/sh ../mkinstalldirs /usr/local/bin
  /bin/sh /usr/local/bin/libtool --mode=install install  -s -o root -g wheel -m 555 cgi-fcgi /usr/local/bin/cgi-fcgi
libtool: install: install -o root -g wheel -m 555 -s .libs/cgi-fcgi /usr/local/bin/cgi-fcgi
Making install in examples
Making install in include
/bin/sh ../mkinstalldirs /usr/local/include
 install  -o root -g wheel -m 444 fastcgi.h /usr/local/include/fastcgi.h
 install  -o root -g wheel -m 444 fcgi_stdio.h /usr/local/include/fcgi_stdio.h
 install  -o root -g wheel -m 444 fcgiapp.h /usr/local/include/fcgiapp.h
 install  -o root -g wheel -m 444 fcgimisc.h /usr/local/include/fcgimisc.h
 install  -o root -g wheel -m 444 fcgio.h /usr/local/include/fcgio.h
 install  -o root -g wheel -m 444 fcgios.h /usr/local/include/fcgios.h
/bin/sh ./mkinstalldirs /usr/local/include
 install  -o root -g wheel -m 444 fcgi_config.h /usr/local/include/fcgi_config.h
===>   Compressing manual pages for fcgi-devkit-2.4.0
===>   Running ldconfig
/sbin/ldconfig -m /usr/local/lib
===>   Registering installation for fcgi-devkit-2.4.0
===> SECURITY REPORT: 
      This port has installed the following files which may act as network
      servers and may therefore pose a remote security risk to the system.
/usr/local/lib/libfcgi.so.0

      If there are vulnerabilities in these programs there may be a security
      risk to the system. FreeBSD makes no guarantee about the security of
      ports included in the Ports Collection. Please type 'make deinstall'
      to deinstall the port if this is a concern.

      For more information, and contact details about the security
      status of this software, see the following webpage: 
      http://www.fastcgi.com/

h) Compile test FCGI application and run it:

bsd# cd /usr/local/www/hiawatha/
bsd# cat fastcgi.c 
#include <stdio.h>
#include <stdlib.h>
#include <fcgiapp.h>

#define printf(...) FCGX_FPrintF(request->out, __VA_ARGS__)
#define get_param(KEY) FCGX_GetParam(KEY, request->envp)

void handle_request(FCGX_Request *request) {
        char *value;

        printf("Content-Type: text/plain\r\n\r\n");
        if ((value = get_param("REQUEST_METHOD")) != NULL) {
                printf("%s ", value);
        }
        if ((value = get_param("REQUEST_URI")) != NULL) {
                printf("%s", value);
        }
        if ((value = get_param("QUERY_STRING")) != NULL) {
                printf("?%s", value);
        }
        if ((value = get_param("SERVER_PROTOCOL")) != NULL) {
                printf(" %s", value);
        }
        printf("\n");
}

int main(void) {
        int sock;
        FCGX_Request request;

        FCGX_Init(); 
        sock = FCGX_OpenSocket(":2005", 5);
        FCGX_InitRequest(&request, sock, 0);

        while (FCGX_Accept_r(&request) >= 0) {
                handle_request(&request);
                FCGX_Finish_r(&request);
        }

        return EXIT_SUCCESS;
}
bsd# g++ -Wall -I /usr/local/include -L /usr/local/lib -lfcgi fastcgi.c -o fastcgi
bsd# ./fastcgi 
^Z
Suspended
bsd# bg
[1]    ./fastcgi &
bsd# sockstat | grep fastcgi
root     fastcgi    4151  3  tcp4   *:2005                *:*

i) Configure Hiawatha:

bsd# /usr/local/etc/rc.d/hiawatha stop
Stopping hiawatha.
Waiting for PIDS: 675.
bsd# vi /usr/local/etc/hiawatha/hiawatha.conf
/usr/local/etc/hiawatha/hiawatha.conf: 105 lines, 2214 characters.
bsd# cat /usr/local/etc/hiawatha/hiawatha.conf

# Hiawatha main configuration file
#

# GENERAL SETTINGS
#
#ServerId = www-data
ConnectionsTotal = 150
ConnectionsPerIP = 10
SystemLogfile = /var/log/hiawatha/system.log
GarbageLogfile = /var/log/hiawatha/garbage.log

# BINDING SETTINGS
# A binding is where a client can connect to.
#
Binding {
        Port = 80
#       Interface = 127.0.0.1
#       MaxKeepAlive = 30
#       TimeForRequest = 3,20
}
#
#Binding {
#       Port = 443
#       Interface = ::1
#       MaxKeepAlive = 30
#       TimeForRequest = 3,20
#       SSLcertFile = hiawatha.pem
#}

# BANNING SETTINGS
# Deny service to clients who misbehave.
#
#BanOnGarbage = 300
#BanOnMaxPerIP = 60
#BanOnMaxReqSize = 300
#KickOnBan = yes
#RebanDuringBan = yes

# COMMON GATEWAY INTERFACE (CGI) SETTINGS
# These settings can be used to run CGI applications. Use the 'php-fcgi'
# tool to start PHP as a FastCGI daemon.
#
#CGIhandler = /usr/bin/perl:pl
#CGIhandler = /usr/bin/php-cgi:php
#CGIhandler = /usr/bin/python:py
#CGIhandler = /usr/bin/ruby:rb
#CGIhandler = /usr/bin/ssi-cgi:shtml
#CGIextension = cgi
#
FastCGIserver {
        FastCGIid = QFastCGI
        ConnectTo = 127.0.0.1:2005
        SessionTimeout = 30
}

# URL TOOLKIT
# This URL toolkit rule was made for the Banshee PHP framework, which
# can be downloaded from http://www.hiawatha-webserver.org/banshee
#
UrlToolkit {
        ToolkitID = bsd_toolkit
        RequestURI exists Return
        Match .* UseFastCGI QFastCGI
}

# DEFAULT WEBSITE
# It is wise to use your IP address as the hostname of the default website
# and give it a blank webpage. By doing so, automated webscanners won't find
# your possible vulnerable website.
#
Hostname = 127.0.0.1
WebsiteRoot = /usr/local/www/hiawatha
StartFile = index.html
AccessLogfile = /var/log/hiawatha/access.log
ErrorLogfile = /var/log/hiawatha/error.log
#ErrorHandler = 404:/error.cgi

# VIRTUAL HOSTS
# Use a VirtualHost section to declare the websites you want to host.
#
VirtualHost {
        Hostname = bsd.speedport.ip
        WebsiteRoot = /var/www/bsd/public
        AccessLogfile = /var/www/bsd/log/access.log
        ErrorLogfile = /var/www/bsd/log/error.log
        TimeForCGI = 5
        UseToolkit = bsd_toolkit
}

# DIRECTORY SETTINGS
# You can specify some settings per directory.
#
#Directory {
#       Path = /home/baduser
#       ExecuteCGI = no
#       UploadSpeed = 10,2
#}

j) Set up directories and restart Hiawatha:

bsd# mkdir -p /var/www/bsd/public
bsd# mkdir -p /var/www/bsd/log
bsd# /usr/local/etc/rc.d/hiawatha start
Starting hiawatha.
bsd# curl bsd.speedport.ip
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>404 - Not Found</title>
<style type="text/css">BODY { color:#ffffff ; background-color:#00000a }
DIV { font-family:sans-serif ; font-size:30px ; letter-spacing:20px ; text-align:center ; position:relative ; top:250px }
</style>
</head>
<body>
<div>404 - Not Found</div>
</body>
</html>
bsd# touch /var/www/bsd/public/index.html
bsd# curl bsd.speedport.ip
bsd# 

Back at square one, unfortunately.

I hope this is detailed enough for you to be able to spot any errors I have made in the setup and configuration.

If you add one or more random character to your URL (for example http://bsd.speedport.ip/blah) it should work (assuming that the file /blah does not exist). Right?

If that's the case, remove the RequestURI line from your bsd_toolkit UrlToolkit rule. Why it goes wrong is because when you use 'curl bsd.speedport.ip', the URL '/' is requested. The URL '/' points to the document root of the bsd.speedport.ip website. Of course, that directory exists and causes the UrlToolkit to return because of the 'RequestURI exists Return' line.

Hope this clears things up.

Hugo,

You're right - it worked!

In the end, although deleting my document root would have worked, it would also have meant I could not link to pictures or css stylesheets hosted on the same virtual host. So I settled for a small modification of the URL toolkit properties - my configuration now reads as follows:

UrlToolkit {
        ToolkitID = bsd_toolkit
        Match ^/ UseFastCGI QFastCGI
        RequestURI exists Return
        Match .* UseFastCGI QFastCGI
}

Everything else in my hiawatha.conf is the same (i.e. as above.)

This should allow me to link to static content (like pictures, css stylesheets, etc) within the document root, but jump straight to the FastCGI app when someone fires up a browser (or uses curl) and points it at my machine.

Thank you very much for your patience and help. I will develop a complete HOWTO out of this and post it on my own forum (sunwcall.com) - I'll also mail you a copy for use on your site. FastCGI is an interesting technology and I'd really like to explore it in detail, especially using Hiawatha as a web server.

In that case, you could also use the following:

UrlToolkit {
        ToolkitID = bsd_toolkit
        RequestURI isfile Return
        Match .* UseFastCGI QFastCGI
}

FastCGI is indeed very interesting. You should take a look at Hiawatha's FastCGI load balancing feature. Something I'm really proud of.

Even better - thanks!

Next topic, I think, will be investigating FastCGI applications with inter-process communication... I'm thinking of the following architecture:

Browser > Internet > Hiawatha > (multiple FastCGI apps with inter-process communication) > memcached > Database backend

I did have a look at the load balancing feature of Hiawatha. Like most things in Hiawatha, it's neat and well-implemented. (I particularly like the client affinity).

But I have a technical question about the load-balancing architecture - I'm assuming Hiawatha uses its load balancing feature to speed up multiple FCGI requests, by utilising a different FCGI daemon (subject to client affinity) for each thread Hiawatha uses. Is there a way to optimise the number of daemons to the number of threads in Hiawatha? If I have an 8-core machine, I could set up 24 or so FCGI daemons on it - and let Hiawatha do load balancing across all of them, so if the web server gets hammered, I know I can put my multiple CPU cores to good use. As long as maintain data consistency across multiple daemons (I'm thinking of IPC - memory sharing on the same machine, or communication via sockets across multiple machines), it means I can avoid writing multithreaded daemons - and rely on Hiawatha's multithreading to divvy up the workload.

Does this sound reasonable, or would you recommend a different approach? I already know that I can separate responsibilities over different FCGI deamons by simply specifying them in the hiawatha.conf and designating them using the UrlToolkit section (user management, portal index, et cetera.)

Hiawatha uses a different FastCGI server for each client. This way, session don't get disrupted because a FastCGI server might not be aware of sessions of other FastCGI servers. Hiawatha uses round-robin to assign a FastCGI server for each new client. In my oppinion, this is the best way to do so.

You can of course use different FastCGI servers for different sections of the website, but that requires some serious investigation in how much load each website section produces.