thttpd Web Server

The thttpd web server is nothing like Cherokee. Whereas Cherokee provides a lot of configuration options that allow various parts of a site to be located in different places a thttpd server is mainly intended to serve one directory tree, except for some special handling of directories with "~" symbols in.

thttpd is also built very differently to Cherokee. It's a single thread process built out of non-blocking code so one instance of the program handles all inbound requests, as opposed to the more usual practice of coding a server to handle one request at a time and forking multiple instances to handle multiple requests. The single threaded approach has several advantages and disadvantages:

1. Thttpd does not suffer the overhead of forking processes to handle incoming connections.
2. On some systems Thttpd may be subject to a bottleneck where the operating system puts incoming connections in a small queue. To counter this Thttpd places a high priority on accepting connections. Openslug is based on Debian linux, which appears to allow a server to set its own queue size.
3. The Thttpd process can die entirely. On uNSLUng firmware this could be triggered by having a share with a name that conflicts with a directory name in the www directory. One solution used on web servers is a short (two line) respawn script. The script simply runs Thttpd as a foreground task and then loops back to the start.  

The original Linksys firmware contained a modified version of thttpd. The Linksys version maps all Samba shares into subfolders with HTTP authentication identical to Samba authentication. There is no evidence of a cgi program to do this or even the capability to define a program to do it so I am assuming it is hardcoded into Thttpd. Attempting to update Thttpd to a newer version breaks shared folder access.

The package is a bit different too:

1. It adds a startup script.
2. it doesn't have a configuration file by default
3. it doesn't create an example site by default
4. the default location is "/srv/www" which doesn't exist
5. cgi isn't enabled unless you configure it

The html file location is set by the init.d script as follows:

The thttpd pages at acme.com suggest a more elaborate way of starting thttpd, firstly they give a wrapper script:

The script causes thttpd to get its configuration from a file. It also forces Thttpd to run in the foreground so that the script halts until or unless thttpd terminates.

Config file from acme.com:

Note that you probably shouldn't use all these options, under the Debian model "start-stop-daemon" can create the pidfile (process id), also running perl programs under chroot is extremely difficult and probably not worth the extra effort unless you're serving to the internet.

If your perl scripts often end in .pl the cgipat could be **.cgi|**.pl or alternately you might create a cgi-bin directory and use /cgi-bin/* to have every executable in that directory treated as cgi.

File permissions:

Thttpd is picky about permissions, in particular it will only return a file if it is set "world readable". This avoids the silly situation where an html file can be viewed from the internet but not by a logged in user, also it prevents private files being made visible accidentally and allows some logfiles and config files to be located in the www directory without compromising security.

An actual configuration

I'm going to set the directory to /var/www to match my previous cherokee configuration. The cgi-bin folder will be moved from /usr/lib to /var/www. Some permissions will need fixing. For security's sake some permissions should be "broken" e.g. the admin scripts should have their world permissions cleared.

The two start lines in /etc/init.d/thttpd have been patched to set the directory, the cgi pattern and set the user to www-data.