Module types
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.
|