|
|
Encountered Module Types |
|
|
Encountered Module Types
This page follows a request's path from browser to server, through the
various layers of roxen, the module types and to the end of the chain
where the resulting document is sent back again to the browser as the
reply to the request. After reading this, you should have a good grasp
on what happens when and how the various module types fit in the
overall picture.
|
|
For this example walk-through, we will follow a request from
browser through the server and back; the example applies for all
supported protocols. We'll be abstracting all encountered modules by
type instead of by name, since we're getting at the principle rather
than the specifics of a specific server configuration.
Calling Sequence
This is a description of the order of calling modules in roxen.
Generally speaking, an incoming request passes through a number of
type levels, which will be described in turn. A failure at a
type level means that none of the modules of that type could treat the
request. The case where there are no modules of a certain type is a
trivial case of failure.
A failure usually means that the request is passed on to the next
level. What happens when a module succeeds in treating the request
depends on the level, and will be described later for each case in the
roxen modules chapter.
- Protocol Modules
An incoming request enters roxen through the protocol module, which
handles the lower level communication with the client.
- Authentication Modules
If the protocol module got some form of authentication information
from the client, the authentication module is invoked. Regardless of
the success or failure, the request moves on to the next layer. The
authentication status (fail or a valid user identity) is stored in the
request information object.
- First Try Modules
The first try modules get the first shot at returning a response of
some sort to the client. From here on, success or failure means
breaking out of or staying with the flow of the calling sequence;
handled requests are sent back to the client, unhandled are subject
to enter the other module types further down the chain.
- Location Modules
The request now enters a location module; which one depends on the
path accessed. In this respect, the location modules work almost like
your average file system; a given path refers to a certain file entry
on some storage medium somewhere. Or, possibly, a directory entry or a
non-existent file. In either of the latter cases, the request moves
on.
- The Directory Listing Module
The request was found a directory at some earlier level, and it is now
up to the directory listing module to generate some form of directory
listing or representation of the directory at hand.
- File Extension Modules
If some previous level sent handled a request by sending forth a file
down the chain, it is processed by an appropriate file extension
module (if one handling the proper extension was available).
- The Content Type Module
The content-type module tags the resulting page with a suitable
content-type for the file being sent back to the browser. Modules
may of course override this, should they know what they want.
- Filter Modules
All requests then pass through the filter module stage. Filter modules
may process and alter the request at leisure, watermarking, filtering
out information or doing other forms of post processing.
- Last Modules
If no module has yet handled the request, the last modules get a shot
at catching and processing the request before a file not found error is
sent back to the client.
- Protocol Modules
The protocol module which originally set this chain going is returned
the result from previous stages and starts sending the result to the
client in response to the request.
- Logger Modules
Finally, as the result is being transferred back to the client, the
logger modules get their peek at the request. When the logger modules
are done and the whole response is sent to the browser, the request
information object dies and the request is over.
|
|