docs.roxen.comView this page in a printer friendly mode
DocsRoxenWebServer 5.1System Developer Manual JavaA request´s path through Roxen
Copyright © 2013, Roxen Internet Software
Suggestions, comments & compliments


A request´s path through Roxen

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 to the browser. After reading this, you should have a good grasp on what happens when and how the various module types fit in the overall picture.


Module types that can be written in Java will be noted as such.

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 will 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 module. The specific Java module interfaces are described in the Reference for Roxen Java Classes chapter in this manual.

  1. Protocol Modules

    An incoming request enters Roxen through the protocol module, which handles the lower level communication with the client.

  2. 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.

  3. 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.

  4. 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.
    This module has a Java inteface.

  5. 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.

  6. 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).

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

  8. 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.

  9. 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.
    This module has a Java inteface.

  10. 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.

  11. 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.