Forum

In hiawatha it seems only possible to match on the extension, not on the URI or a directory.

Imagine a simple use case, where all the requests made to:

http ://192.168.0.1/img/...
http ://192.168.0.1/css/...
http ://192.168.0.1/js/...

should just return the file requested.

And the requests made to other URI should be forwarded to the FastCGI server:

http://192.168.0.1/home
http://192.168.0.1/admin
http://192.168.0.1/config

This cannot be done in hiawatha, because I am required to match with an extension:

Hostname = 192.168.0.1
WebsiteRoot = /var/www-docroot
StartFile = index.fcgi
ExecuteCGI = yes
FastCGI = FCGIAPP
    
Binding {
	Port = 80
}

FastCGIserver {
    FastCGIid = FCGIAPP
    ConnectTo = 127.0.0.1:1234
    Extension = fcgi
}

In lighttpd I can do it like this:

server.document-root = "/var/www-docroot/"
server.port          = 80
server.modules       = ( "mod_fastcgi" )

$HTTP["url"] !~ "^/(css|img|js)/|/favicon\.ico$" {
    fastcgi.server   = ( "/" =>
                             ((
                                "host" => "127.0.0.1",
                                "port" => 1234,
                                "check-local" => "disable",
                             ))
                       )
}

In cherokee I can do it like this:

server!port = 80
vserver!default!document_root = /var/www-docroot

vserver!default!directory!/!handler = fcgi
vserver!default!directory!/!handler!balancer = round_robin
vserver!default!directory!/!handler!balancer!type = interpreter
vserver!default!directory!/!handler!balancer!local1!host = localhost:1234
vserver!default!directory!/!priority = 1

vserver!default!directory!/css!handler = file
vserver!default!directory!/css!priority = 2

vserver!default!directory!/img!handler = file
vserver!default!directory!/img!priority = 2

vserver!default!directory!/js!handler = file
vserver!default!directory!/js!priority = 2

Thanks for your help!

In Hiawatha, it is also possible. It can be done via URL rewriting. All existing files are requested as usual. All requests to non-existing files will be rewritten to /index.fcgi, which will be redirected to the FastCGI server.

Hostname = 192.168.0.1
WebsiteRoot = /var/www-docroot
StartFile = index.fcgi
ExecuteCGI = yes
FastCGI = FCGIAPP
RewriteURL = to_fcgi

Binding {
    Port = 80
}

UrlRewrite {
    RewriteId = to_fcgi
    Match ^/$ Return
    RequestURI isfile Exit
    Match /(.*) Rewrite /index.fcgi
}

FastCGIserver {
   FastCGIid = FCGIAPP
   ConnectTo = 127.0.0.1:1234
   Extension = fcgi
}

The index.fcgi does NOT need to be present on disk. See it as a virtual file, to trigger Hiawatha to send the request to the FastCGI daemon

Is this what you want?

It works with the FastCGI daemon (the requests are forwarded, and the
browser shows the output).

However, for the other files (CSS, images,...), it returns 403 Forbidden.

Any idea why?

Thanks!

Could it be because Hiawatha can't read the files? What does the ErrorLogfile tell you?

I've tested it myself and it worked for me.

I just needed to add "FollowSymlinks = yes"

Thank you very much for your help!

It's good to hear everything is working now. I'd like to hear from you what you think of Hiawatha. Things you like and specially thinks you don't like. So I can improve Hiawatha.

Thanks for helping users like you do!

Hiawatha is great, because it is the lighttest FastCGI webserver available (less than 130kb on my platform).

What I don't really like is having to put an extension and define a rewrite URL (I had to enable them with ./configure, and it makes the binary bigger) for FastCGI, instead of simply matching by URI.

Another thing I find annoying is the Banning options. I didn't manage to completely disable banning, but maybe I haven't found the good combination of options.

It could also be great to be able to combine the configuration files in only 1 file (I only have 1 virtual host and 4 lines in the mime config file), and then: hiawatha -f /etc/hiawatha.conf insted of giving a whole directory.

I think hiawatha could target developers of embedded systems, and its size could be reduced even more without too much work. For example, let the user disable threads, and use CYaSSL (http://www.yassl.com) instead of OpenSSL. And maybe a configure option --enable-small that would strip out most of the features like Ban,...

Thanks again, and keep up the good work!

I agree it can be seen as a configuration-hack to make thinks work. On the other hand, Hiawatha always uses the extension to determine how to handle files. This makes it consistent in how it works. And because of this consistency, the result is easy code which results in lesser security problems. It's also that every piece of software works in its own way. Hiawatha ain't Cherokee or Lighttpd, so it's likely it doesn't work like those two. So, I'd really appriciate if you use Hiawatha for a while, get used to its configurationsyntax and after that let me know if you still think the FastCGI-rewrite way is not a good way to do it.


The only banning option that is enabled by default is BanOnMaxPerIP, and only for 2 seconds (to block DoS-ers). You can disable it by using BanOnMaxPerIP = 0. By doing so, Banning is completly disabled. And if you want some more quaranty, use BanlistMask = deny:all Via this setting, no IP ends up in the banlist.


The mimetype file is in most cases very large. Therefor I think it's nice to have it in a seperated file. Can you explain why you want them in one file? What problems do you experience with having those in a seperated file?


Disabling threads is not an option. It's part of the core of Hiawatha. Hiawatha has to be able to handle multiple connections. Forking is slow, so threading is the only way.

About SSL, I'm not really a big fan of the OpenSSL API, but it is available on almost every platform. Which is not the case for the other SSL libraries available.

About the --enable-small, I will see if there are some Hiawatha features which are suitable for enabling or disabling them during compiling and at the same time make the binary significantly smaller. But I doubt if there are any.