About Trollsilm
Technology
Prices and distributors
Contact
WebShop

Clutter Free Enterprise

Dihturnoaidi
LinkedIn

Gard's Universal Daemon

Version 4.0
Modular, light weight web server

Status: Free / OpenSource
License: Trollsilm Open v1.0
Source last modified: 04-Aug-2002
Download: gud40.tgz

History

At less than 40k, Gud does a lot for its size. Development with the first version of Gud started with a gopher server in 1993. During spring of 1994 and with the lack of documentation on HTTP (there was no Google back then), HTTP had to be reverse engineered. Thus started the story of a daemon that could serve both HTTP and gopher requests from the same configuration. Since then, the server has been rewritten three times to get cleaner and more modular code. Version 4 started its development in 1996.

Why use Gud?

It's easy to configure, small, and currently enjoying

Package

The package unwraps to ptr/www/src/gud40. Within this directory, you find the following important files and directories:
src/ - Directory for the main source code
bin/ - Directory for binaries
gud.conf - default configuration file
mime.types - list of MIME file-types.

Compiling

In order to compile brand new binaries from the source, enter the src/ directory and start the script newGud .
Once you have new binaries, you can assemble a new copy of Gud by entering the bin/ directory and run the script make_gud . The script asks for each module if you wish to include it or not. You should reply by entering 'y' or 'n' for yes or no. If you decide not to include a module at this stage, the support for it does not go into the final binary, and will therefore not be available at run-time until you make a new binary.

You can include all modules automatically by adding the 'y' parameter to make_gud: make_gud y
You can exclude all modules automatically by adding the 'n' parameter to make_gud: make_gud n
Do note that if you do not include any modules, the server will only be able to deliver static pages. But then again, perhaps that's all you want it to do.

Starting Gud

Default Gud configuration file is /home/god/etc/gud.conf
You override with the -f parameter. Hence, your starting command is probably:
Gud40 -f/etc/gud.conf & or similar.
All defaults can be found (and modified) in src/defaults.h

gud.conf

The configuration files is split into several segments. Each start of a segment is noted by a separate line with hard brackets containing the segment name. At least two modules must be there: [Global] and [Module]. In addition, you can have overriding segments for each website, eg. [trollsilm.com.var] for variables overriding [Global] on the trollsilm.com website and [trollsilm.com.mod] for a separate [Module] segment specifically for the trollsilm.com website.

[Global] or [website.tld.var]

The following variables are defined here:
home - Default web site directory *)
index - Default index file for any directory. Typically index.html
port - Default listen port. Typically 80
input_timeout - Number of seconds silence from the client before timing out the connection.
pack_timeout - Number of seconds to attempt sending a package of data before timing out the connection.
pack_size - How many bytes to attempt sending in each package of data.
gopher-self-redirect - Name of server when redirecting / indexing.
http-self-redirect - Default servername when redirecting HTTP (if server name is not included in HTTP-request)
http-sub - Personal web page subdirectory for URLs with tilde-format.
mime-types - File containing the extention-to-mime-type mapping.

[Modules] or [website.tld.mod]

For any website and any request, the modules section is parsed line by line for a match. If no match is found, or no match stops the processing until the end of the segment, the file (if found) is returned to the client as a flat file. The segment contains one match per line, and all parameters are tab-separated.

The first column contains match criteria, using * as a wildcard. The wildcard functionality is limited and should be used only in the beginning and the end of a criteria. E.g. *.html or mydir/* or *.zip/*

If the criteria matches he currently requested file, the second column contains the name of the module to be run. Every column thereafter are parameters to the module, and hence the third column will be referred to as first parameter, fourth column will be referred to as second parameter, and so on.

Alias-module

Generates an HTTP redirect to contents of first parameter. The server name is expected to remain the same, and should therefore not be included. The module halts further parsing.

Extern-module

If no paramters are given, the file accessed is assumed to be a Gud-script and are passed with the following parameters:
Original URL in original coded format
Name or IP of connecting client
Sender-field from HTTP-header.

If parameters are given, the executable in first parameter is run with the remaining columns as parameters. Inserting %a anywhere in the parameters will allow passing the name of the file requested.
The current work directory for the executable will be the top directory of the web site accessed.

Unlike CGI-scripts, a Gud-script does not have to decode the request by itself. POST and GET are handled the same way; parameters passed to the server are decoded and passed to the script in the form of environment variables. It is therefore possible to write a Gud-script in your preferred shell. The caveat is the maximum size of environment variables set in your kernel. Also see environment variables below.

This module halts further parsing.

ExtHead-module

The ExtHead-module is actually the same as the Extern-module. You must include the Extern-module to get ExtHead. The only difference between the two modules is that Extern outputs a full HTTP header, so that the external command does not have to create one by itself. If, on the other hand, your application wants to produce its own header, you should use ExtHead to avoid the automatic creation of one. You should use ExtHead for the slobml-programme for SQML-support.

Logger-module

Appends second parameter to file specified in first parameter. Variables can be substituted by quoting them in the form $VARIABLE$. E.g. 2007.12.08$ to insert the date, $CLIENT$ to insert the user-agent, etc. Variable spaces searched for the quoted name are: DATE, HTTP-header, request parameters, configuration variables (global or site-specific). Also see environment variables below. This module allows further parsing of the modules-segment.

Packer-module

Assumes that the match is an archive, and you want to extract a file from it. The first parameter tells the module which extention constitutes the archive, and allows the module to split archive name from file name. So in the requested file moduletest.zip/testme.html, a first parameter of '.zip' allows the module to see that the archive name is moduletest.zip and the filename is testme.html.

The remaining parameters tells how to retrieve the file from the archive to stdout. Use %a to insert the archive name and %f to insert the file name. Eg. /usr/bin/unzip -p %a %f allows file %f to be extracted from the zip-file %a to stdout. This is then redirected to the client.

This module halts further parsing of the modules-segment.

CGI-module

Dysfunctional.

Gud Map-module

Implementation of server side imagemapping. The file that matches the criteria is passed to Gud Map as the mapping file.
The HTML "<a href=mymap.map><img src=blah.gif ismap></a>" will produce a request for mymap.map?x,y, where x and y are the coordinates for the location of where on blah.gif you clicked. Upper left corner is 0,0.

The mymap.map file would be passed to the Gud Map module. The file lists one area and URL for each line. Lines are in the format of:
x1,y1,x2,y2,URL
The first match of a point within the square (x1,y1)-(x2,y2) generates a redirect to URL.
Any information not included in the URL is assumed:
If protocol is omitted, http is assumed.
If server is omitted, the same server name is assumed.
If directory is omitted, the same directory is assumed.

Protect-module

Gives support for basic HTTP authorization. Name of password file must be given as first parameter.
The password file contains one username and password per line in the format user:password in clear text.
If password file is not found, a 404 is produced and parsing is halted.
If password file is found and no correct authorization is given with the request, a 401 is produced and parsing is halted.
If authorization is given, the environment variable Authorization is set with the user name and parsing of the modules segment proceeds.

Environment variables

Environment variables may be quoted for the Log module and are also passed to all external executables. Variables set are:
ACCEPT - Accept-list from HTTP-header
BROWSER - User-agent from HTTP-header
SERVER - Server-part of URL.
COOKIE - Cookie from HTTP-header.
Authorization - User name from Protect-module (if any).
All parameters from URL in decoded form.

A good way to see all environment variables is to have a bash script test.gud.txt containing only one line: export
The .txt-extention will tell the Gud server to output text/plain at content type, allowing you to easily read the output of the script without any modifications for html.

Setting up a web page

You don't have to set up a variable-segment for each web site in order to tell it about a new site you're hosting. Sites are automatically found if put in the /ptr/www-directory. Hence, trollsilm.com is automatically found if put in /ptr/www/trollsilm.com. 404-pages are found as 404.html.

Hidden SQML-support

Gud 4.0 has built in conceilment of sqml-files. That is, an sqml-file can be perceived as a directory in the URL. So even though the file requested is directory/script/param1/param2, Gud will find out that there is a directory/script.sqml, and param1/param2 are passed as parameters.

Trollsilm Tuur-Eggesbø, Davviluohkká 16, 9520 Guovdageaidnu, Norway - gard at trollsilm.com