Running FastCGI application

4 April 2007, 19:32
Hiawatha rules

I have compiled it with ./configure --disable-ssl --disable-cache --enable-fastcgi and it works very fine. Also CGI apps work great. This project simply is great. I really like the code itself as well.

There's really only one thing I have not been able to figure out, how do I run FastCGI applications in stead of having them run as regular CGI scripts?

To test this, I use:
#include <stdlib.h>
#include "fcgi_stdio.h"

int main(void)
int count = 0;
while(FCGI_Accept() >= 0)
printf("Content-type: text/html\r\n\r\n<title>FastCGI Hello!</title><h1>FastCGI Hello!</h1>Request number %d running on host <i>%s</i>\n", ++count, getenv("SERVER_NAME"));
return 0;

Compiling it with gcc -lfcgi test.c -o test.fcgi

This test code works ok on Apache, proven when the count number increases on each page refresh.

However, I can't seem to get it to work in Hiawatha. There it always runs the test.fcgi as regular CGI. It runs it and closes it so the number is always 1.

How can I get this to work with Hiawatha? Can it work?

Hugo Leisink
5 April 2007, 12:28
First of all, FastCGI is always enabled in Hiawatha, so the --enable-fastcgi is not necessary.

I've looked at your program and the FastCGI library you used. It' looks like it's a kind of FastCGI Hiawatha does not support. What Hiawatha does support is that a FastCGI program must become a daemon and listen to a port. Hiawatha will connect to this port and send the FastCGI request.

What your program expects is that during startup, Hiawatha starts this test.fcgi and keeps it in memory. For certain requests, Hiawatha should send the request to a pipe (shared with this test.fcgi) and read the results from it.

It's another FastCGI method which Hiawatha does not support.... yet. I'll consider it a feature request.
5 April 2007, 17:23
Thanks for the help Hugo (bedankt voor de hulp)

On second thought, I think it might be more wise for me to run my program as a daemon. This primarily in relation to load balancing and further also to have more platform independent process control (plus easier debugging).

I will definitely keep considering using Hiawatha. Why would you advice someone to use Hiawatha over Lighttpd? I guess my question is more like, what would over time remain crucial differences between these two, despite adoption rate or feature support?
Hugo Leisink
5 April 2007, 21:27
Why would you advice someone to use Hiawatha over Lighttpd?

What I really appriciate is software that is easy to configure. If I need a mailserver, I don't like that I first have to become an SMTP expert before becoming able to configure a mailserver. With this idea I wrote Hiawatha. I want users who are not a HTTP or a (Fast)CGI expert to be able to setup a webserver. I've received a lot of email from users who wanted to let me know how easy they find Hiawatha to configure. And when I look at the Lighttpd or Apache configuration format, I think I've done indeed a nice job.

Second reason: my code is secure. This is what I really think. If you don't believe me, prove me wrong. I've actually challenged some people who said that it's so easy to say your software is secure. Everybody does. That's true, but after I challenged them I've never heard from any of them again. And my websites have never been defaced
6 April 2007, 23:36
I don't want to waste your time too much with my question here, but I am now trying to make a CGI daemon. The problem is I cannot understand or read anywhere what I need to talk back to via the socket. That's not Hiawatha's fault, just that I can't seem to figure this out.

I have a test server app opening a socket at port 2001, then when I have Hiawatha running, I can point my browser to a page and I can see that the socket (my app) is responding and can send stuff back. But all the browsers tells is a 500 internal error.

I send this via the socket:
int  byteCount;
byteCount = fprintf (stdout, "HTTP/1.1 200 OK\nContent-type: text/html\n\n<h1>Hello there</h1>");

if (send(new_fd, "HTTP/1.1 200 OK\nContent-type: text/html\n\n<h1>Hello there</h1>", byteCount, 0) == -1)

Yes it's a bit clumsy, just trying things out here. The socket responds correct, but frankly I have not much of a clue what I am supposed to do or what is expected for me to send so that I can serve valid to Hiawatha as a FastCGIserver daemon.

I looked and looked around on the net and it tells me nothing about how to go about writing a CGI daemon in relation to what I have to with the socket to send correct html and parse the GET parameters etc. All of this I have done successfully in CGI, so I am not completely in the dark, just at this point. Probably I am misunderstanding something here.

Is it possible that you can provide my with a little hint here? I realize that I shouldn't waste to much of your time with this, but all I need to figure out is this socket issue and then I can complete my daemon foundation.

In my httpd.conf I have:
FastCGIserver {
FastCGIid = FCGI
ConnectTo =
Extension = aaa

..and there lies another question which I can't figure out at the moment. All I want is to have a daemon running which Hiawatha can talk to via a socket for me to still have common CGI environment stuff. But now here it seems I need to provide a file Extension, but the extension would be kind of irrelevant and only serve to point to the fastcgi process?? I am not going to have php files or a custom script language, just a CGI daemon.

You can see that I am kind of confused here. I want to still have access to all CGI environment variables (which the socket seems to provide).

All the help is appreciated and really this is my only last issue to get it going for me. Thanks regardless.
6 April 2007, 23:43
I should add that the \n\n and \r\n issue is not causing the 500 error. I just can't figure this one out.
Hugo Leisink
7 April 2007, 01:50
Your daemon needs to talk the FastCGI protocol. You can find it here:

It is not a very clear document, so you might have to read it more than once. If you have any questions, don't hesitate, just contact me. That's why I started this forum.
9 April 2007, 15:06
Thanks, yes it looks like I simply need to get familiar with the FastCGI protocol. I will be using Hiawatha and see what I can do to support it.
11 April 2007, 08:08

The FASTCGI configuration of Hiawatha is biased in favor of interpreters, which makes it unsuitable for application servers.

I have an application server and I would like to configure the web server to that any request below a certain URI gets relayed to the application server.
for exemple I could do:
Location {
URL = /myapp
And then requests to /myapp/search, or /myapp/checkout get relayed to the application server without any interpretation by the web server.

RIght now with Hiawatha I am forced to introduce a dummy extension (.ma) for the MYAPP FASTCGI server and dummy files:
$touch /var/www/myapp/

Which of course doesn't work, because I don't want these extensions, the application server generates new URI all the time and hiawatha shouldn't check for the existence of these files in the first place.

Any chance of seeing Hiawatha support this type of configuration ? This is a show stopper for anybody with such an application server.

Thanks for your reply
Hugo Leisink
11 April 2007, 11:57
At the moment I am working on this kind of FastCGI application support. The way I am implementing it is this:

You specify a FastCGI extension:
FastCGIExtension = fcgi

I am not going for the URI thing you described. If you want a FastCGI application to handle more than 1 page, you have to use GET variables to handle this thing. For example via a 'page' variable:

I think it will be more clear to users this way. Besides secure, I want my webserver to be 'easy to configure'.

I think it will be ready before the end of this month.
Hugo Leisink
24 April 2007, 17:24
I've been busy with the non-daemon FastCGI support in Hiawatha, but it turned out that it requires really nasty code and ugly tricks to get it implemented, so I will skip it. Hiawatha will only support FastCGI daemon applications (applications that open a port to which Hiawatha can connect). The FastCGI devkit [] has support for writing FastCGI daemon applications.

The tool cgi-fcgi [] can run your non-daemon FastCGI program as a daemon.
This topic has been closed.