Map module

URL to physical file mapping

Overview
The map module is responsible for translating the client request to a physical file location on the server. Using the map module you can :

The map module must be loaded for the server to function correctly.

Configuration

User Home Directories

Most sites allow users to have personal web pages stored in their home directories. This feature can be enabled by selecting 'On' for home directory mapping.

If enabled, the web server will map the URL:

http://machine/~username

to the physical file location:

/home-directory/username/html-directory

Where /home-directory/ is the location of the parent directory containing the user's home directory. The user's home directory can be read from a user database file, for example /etc/passwd, or you can set a fixed home directory path for all users. In the latter case the request will be mapped to /home-path/username/html-directory.

If you are using a user database, the file specific should be in a UNIX /etc/passwd style, containing the following information:

   username:*:*:*:*:homedir:*
Fields marked as * are ignored by the server. The user database file is loaded into an internal high performance database, so thousands of users can be accommodated. Any changes to the user database file will be noticed by the server and used immediately.
The /html-directory is the name of the directory within the users home directory which contains the users web pages. By default this is set to public_html.

The home directory prefix '~' is traditionally used to indicate that the url is to be mapped to a home directory. However, you can change this to something else, such as 'users/' or even the empty string.

For example, if the home directory prefix is set to users/, then urls which resemble:

http://machine/users/username

will be mapped to the physical file location:

/home-directory/username/html-directory

Using an LDAP server for homedirectories

Zeus may be configured to use an external LDAP server to perform the mapping of ~username to a physical location on disk. For more information, see the LDAP homedirectory page.

Aliases

Aliases allow you to map files and directories that are outside of the document root into the document tree. They are also used to store CGI programs, FastCGI programs and ISAPI programs. Using dedicated directories for these program files increases the security of your site and allows the server to execute the programs in the correct manner.

The "Docroot path" field contains the virtual path used to reference the files or directories. The "Filesystem directory" field contains the physical file or directory location on the server. The "Alias type" select box list the different types of aliases available.
Alias Type Function
CGI The directory contains regular CGI programs.
FastCGI The directory contains FastCGI programs.
ISAPI The directory contains ISAPI extensions and filters.
Simple The directory contains regular files.

Click the "Add New Alias" button to commit the changes. To delete an alias entry, click on the delete button.

Handlers

Handlers allow files to be processed by external applications before being sent to the client. This allows additional processing to take place on the file, such as executing embedded scripting languages, or additional actions to take place, such as custom access control or logging. A handler maps a specific file extension to a specific content generation element, such as a CGI program, ZDAC extension or ISAPI extension.

For additional information on installing PHP/FI, a third party scripting and database connectivity tool, please see the associated documentation.

By default the handler is responsible for returning 404 errors when the input files are not present. Some handlers, for example PHP/FI do not do this correctly. In this case, you can configure Zeus to check for the files first, allowing the 'correct' response of 404 to be returned.

The file extension should be the extension of the files you wish to be processed by the handler. The file extension should not be prefixed with ".". The handler should be a content generation element and should be referenced from its location in the docroot, not its absolute location. The content generation element should live inside one of the alias sections described above, such as a cgi-bin alias.

Click the "Update" button to commit the changes. To delete a handler entry, tick the "delete" box, and click the "Update" button.

SSI Handlers

SSI Handlers allow you to create new SSI tags, and modify the behaviour of existing SSI tags.

They do this by allowing you to re-map SSI tags on to internal URI requests. For example, you can specify that the SSI tag 'foo' is to be handled by the URI '/cgi-bin/handler.cgi'. This causes the web server to handle the the SSI fragment '<!--#foo-->' as if it were the fragment '<!--#include virtual="/cgi-bin/handler.cgi"-->'.

Additional parameters to the SSI tag are encoded as a QUERY_STRING for the handler. The QUERY_STRING provided to the top level document is available in DOCUMENT_ARGS, and the URI of the top level document is available in DOCUMENT_URI.

An SSI tag can be re-mapped onto any type of URI request - CGI, fastcgi, ISAPI, etc. You can also re-map existing tags (except '#include'). For example, you could remap the 'exec' tag on to a handler which examined the 'cmd="..."' parameter and only allowed certain permitted commands to be executed.

If the handler was called from an internal SSI request, the DOCUMENT_URI information is always available. If it was called directly (from an external HTTP request), DOCUMENT_URI is not present.