Quick SSI Question

10 July 2010, 09:14

Hiawatha version:
Operating System:
I've been thinking about ditching apache for hiawatha but I haven't seen anything in the support section about server-side includes. Sorry if this is a dumb question, but does hiawatha support ssi? Can I just <!--#include virtual="whatever" --> like on apache? Do i need to enable anything? Apache has XBitHack - does hiawatha need pages with includes to have the suffix .shtml or is there some other way to do it?


Hugo Leisink
11 July 2010, 18:27
Hiawatha itself does not support SSI, but I've included a tool which can: ssi-cgi. Use this tool as the parser for s.html files and you're done. Includes are supported, but not all of the SSI commands are. See the execute_ssi_command() function in ssi-cgi.c to see which SSI commands are supported.
11 July 2010, 19:59
Sorry, I don't really understand how to do any of that. Where is ssi-cgi.c? How do I use it as the parser? Do you think you could point me to somewhere where it's explained in more detail?

thanks again, though. I started messing around with this and most of it's been really really straighforward, which is a huge deal coming from apache.
Hugo Leisink
11 July 2010, 20:19
ssi-cgi come with Hiawatha. If you installed Hiawatha, ssi-cgi should already be there. Probably located in /usr/bin. Use the following setting in hiawatha.conf and it all should work:
CGIhandler = /usr/bin/ssi-cgi:shtml

Note that SSI is handled as a CGI script, so it's not very fast. If you have some programming skills, it should be very easy to convert ssi-cgi.c to a FastCGI application which makes it as fast as Apache's SSI.
11 July 2010, 20:50
hm. I did that but it seems like all shtml files are displaying as a text instead of html.

here is the page in question:

if I change it to CGIhandler = /usr/bin/ssi-cgi:html, every page returns a 403 forbidden. I know that's not the best idea speed-wise, but I just figured to see if it would work.
Hugo Leisink
11 July 2010, 20:54
Does /usr/bin/ssi-cgi exist? Where is the hiawatha binary located?
11 July 2010, 21:29
/usr/bin/ssi-cgi does exist. I don't really know where the hiawatha binary is, but I didn't do anything weird during installation. I'm running ubuntu server and installed by making a .deb, exactly like the first HOWTO.
11 July 2010, 22:05
Oh. I think I may have forgotten to restart hiawatha after doing that. Now, however, .shtml files are 403 forbidden also.
Hugo Leisink
11 July 2010, 22:28
What does the error logfile say?
11 July 2010, 23:25
a bunch of "Sun 11 Jul 2010 15:11:17 -0500||/var/www/home/index.shtml|CGI execution not allowed".

Should I chmod +x ssi-cgi ?
11 July 2010, 23:29
okay, I tried that and no luck
Hugo Leisink
12 July 2010, 06:18
Please, post your configuration file.
12 July 2010, 08:42
# Hiawatha main configuration file

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

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

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

# 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 = PHP5
# ConnectTo =,
# Extension = php, php5
# SessionTimeout = 30

# This URL toolkit rule was made for the Banshee PHP framework, which
# can be downloaded from
#UrlToolkit {
# ToolkitID = banshee
# RequestURI isfile Return
# Match ^/(css|files|images|js)/ Return
# Match ^/(favicon.ico|robots.txt|sitemap.xml)$ Return
# Match .*\?(.*) Rewrite /index.php?$1
# Match .* Rewrite /index.php

# 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 =
WebsiteRoot = /var/www
StartFile = index.html
AccessLogfile = /var/log/hiawatha/access.log
ErrorLogfile = /var/log/hiawatha/error.log
#ErrorHandler = 404:/error.cgi

# Use a VirtualHost section to declare the websites you want to host.
#VirtualHost {
# Hostname =
# WebsiteRoot = /var/www/my-domain/public
# StartFile = index.php
# AccessLogfile = /var/www/my-domain/log/access.log
# ErrorLogfile = /var/www/my-domain/log/error.log
# TimeForCGI = 5
# UseFastCGI = PHP5
# UseToolkit = banshee

# You can specify some settings per directory.
#Directory {
# Path = /home/baduser
# ExecuteCGI = no
# UploadSpeed = 10,2
Hugo Leisink
12 July 2010, 08:55
Try adding "ExecuteCGI = yes" to the DEFAULT WEBSITE section. SSI in Hiawatha is done via an external SSI parser, which is run as a CGI script. So, CGI execution must be allowed for the (virtual) host that uses SSI.
12 July 2010, 10:45
No more 403s but nothing is being included.
Hugo Leisink
12 July 2010, 12:45
Are the SSI commands visible in the source of the requested page? Can you show me the source of your SSI page?
12 July 2010, 19:10
If you go through the browser, you cannot see the SSI commands either on the page or in view source.

The "real" source (i.e. the .shtml file on my hard drive) is
<!--#include virtual="includes/header" -->
<!--#include virtual="includes/footer" -->

includes/footer and includes/header definitely exist; the same page works on apache.
Hugo Leisink
12 July 2010, 20:37
The virtual parameter takes a value that is relative to the WebsiteRoot of that website. Use "#include file" to include a file relative to the .shtml file. So, try changing virtual into file in your .shtml file.
12 July 2010, 20:46
that did the trick. Thanks so much!
12 July 2010, 21:02
okay, okay, one more snag: when trying to include the results of a cgi script, I get the contents of the cgi script instead. If I point the browser directly to the cgi script, however, I get the results.
Hugo Leisink
12 July 2010, 21:10
Use #exec cgi="file" to run CGI scripts.
12 July 2010, 21:30
that gets nothing; you can't see <!--#exec cgi="whatever.cgi" --> through the browser or through view source.
Hugo Leisink
12 July 2010, 23:53
Try <!--#exec cgi="./whatever.cgi" --> Is whatever.cgi printing the right CGI header? I've got it working here...
13 July 2010, 01:06
That's exactly the same. What do you mean printing the right CGI header?
Hugo Leisink
13 July 2010, 09:15
A CGI script must first print a CGI header. Which are lines ended with CRLF ("\r\n" in a programming language). Make sure your CGI script does print those header lines. Test your CGI script by calling it directly via the browser.

You can also try <!--#exec cmd="./whatever.cgi" -->. The difference between cgi and cmd is that cgi requires the script to print a valid CGI header and cmd doesn't.
13 July 2010, 19:26
Huh. I'd been doing one \n at the end of the header. Wow. It's interesting how much will fly by the radar in apache. Anyway thanks so much.
This topic has been closed.