The module type determines how the module should interact with Challenger. Modules of different types will need to implement different API methods. A single module can be of several types, if it implements all necessary API methods.

Each request processed by Challenger will usually result in calls to several modules. Challenger will go through all module types, and for each module type it will call the module with the highest priority, given that the trustlevel, security patterns and mountpoint allows access to that module. If the module returns that it could not handle the request Challenger continues with the module of the same type with the next highest priority, or moves to the next module type if there are no modules left.

If the module did handle the request different things happen depending on the module type and the return value. For some return values the request is finished and will be returned to the browser as is. For other values the processing will continue, the value will be sent as input to modules of other types.

The most common module types are Location and Parser. Location modules handle requests to a mountpoint of the virtual file system. Location modules are in that respect similar to Pike or CGI scripts, with the difference that the URL to a location module is set in the configuration interface.

Parser modules handle one or several RXML tags. It often makes sense to make the functionality of a module available as a RXML tag. This way it will be easy for users to integrate the functionality into their HTML pages.

The module types are:

Authentication

modules handle authentication of users as well as providing user information. The information provided by an authentication module can be used in .htaccess files, modules security patterns or other modules. Authentication modules usually connect to a source of user information, such as NIS or LDAP databases. There can only be one Authentication module loaded in e virtual server.

First try

modules are called before all other module types, except for authentication modules. This is used to catch certain types of requests before they begin being processed. One usage is to access to the web server from certain IP addresses.

URL

modules rewrite URLs. They receive the current URL and may return another. This is useful when a web page is published under several names, when a web page has moved or for IP less virtual hosting.

Extension

modules handle virtual file extensions. They get called before location modules.

Location

modules handle accesses to a certain mountpoint in the virtual file system. They are used to implement access to file systems as well as for making modules that behave like Pike or CGI scripts. Location modules can be used to provide access to files stored in other places than the normal file system, for example a CVS repository. Note that several location modules can be asked to handle a request. For modules that have the same priority the one with the longest matching mountpoint will be called first.

File extension

modules deal with files with a certain extension, such as .html or .gif. This may be utilized to decode compressed files before sending them to the user, turning a data file format into something more humanly readable, or just setting the correct file content type. File extension modules are called if a previous module returned a file object.

Parser

modules define one or more RXML tags. These are the basis for all RXML functionality in Roxen, and enable the administrator to add new tags to the RXML language just by loading a new module.

Directory

modules deal with directory listings and index files. If the requested resource is a directory, the directory module gets called. It will usually try to find a suitable index file, or create a directory listing by using the API to ask all Location modules handling that mountpoint for directory contents. There can be only one Directory module in a virtual server.

Filter

modules work on the almost-ready data, just before it is sent back to the requesting browser. This may be used, as the name suggests, to filter out parts of the data that should not be sent.

Last try

modules are called when all other modules have failed to produce anything at all from the request. Uses include producing nicer error messages as well as redirecting the request to other servers.

Log

modules collect log information, and are called at the same time as the request leaves the server. A log module can be used to supplement or replace the built in log functionality.