Roxen WebServer is a full-featured open-source web server distributed under the GPL license. It runs on a number of different operating systems including Windows, Linux, Solaris and Mac OS X.
Some of the strong points of this server is:
Open source code.
A web-based interface for easy configuration and administration.
The highly regarded Roxen graphics support which can be used for dynamic generation of e.g. headers, images and charts.
Integrated MySQL database.
Server-side programming via RXML, Java, Perl, PHP, CGI scripts and more.
Strong encryption.
Modular architecture where server extensions can be loaded without shutting down the server process.
Platform-independent architecture makes custom modules portable with no extra effort.
Roxen WebServer is a collection of scripts and modules. The start script sets up some essential environment variables to keep dynamic libraries and various other external stuff happy. After a rapid progression of start script argument parsing and setting up paths, it rotates the logs and launches the first Pike script: server/base_server/roxenloader.pike.
Next in turn, the Roxen loader bootstraps the server, making sure some dependencies are met, setting up some constants, and installs Roxen WebServer's own master program, server/etc/roxen_master.pike. This program is responsible for, among other things, the dumping and reloading of programs.
Then, the very core of Roxen WebServer, server/base_server/roxen.pike gets loaded. The configuration of all virtual servers are loaded next, their respective ports get registered and unless the flag --no-delayed-load was passed to the start script, not much more happens next until the first request arrives to a server. This means, of course, this code in a module of yours will not run until a server using the module is needed.
At this stage, the server process is up and will listen to incoming requests on all registered ports. When a request to an uninitialized server is received, Roxen will initialize that server, loading and strapping all of its modules. The request is then sent through the common processing sequence. Your applications will not be affected by the delayed loading. To the application, whether it be a module, a script, an rxml page or a servlet, the delayed loading is transparent and does not interfere with the programming environment.
For the rest of the lifespan of the Roxen process, it will go about its business listening and responding to requests, until terminated with a signal to the process, the start script or by the restart/shutdown administrator action. When the Roxen process receives a SIGHUP signal, it reloads its configuration files. A SIGINT/SIGTERM signal takes down the process and makes the start script spawn off a new one to replace the old one (sending a SIGINT/SIGTERM to the start script shuts down the server without respawning another one).
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.
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.
This module has a Java inteface.
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.
This module has a Java inteface.
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.
Download.
RedHat Enterprise Linux 5 x86: Roxen WebServer 5.4.66 (178.9 MB)
RedHat Enterprise Linux 5 x86_64: Roxen WebServer 5.4.66 (183.2 MB)
RedHat Enterprise Linux 6 x86_64: Roxen WebServer 5.4.66 (179.3 MB)
Source code: Roxen WebServer 5.4.66 (28.2 MB)
Install.
- Download the appropriate file for your operating system.
- Run the binary using the "sh" command like this:
sh roxen-5.4.xxx-....sh
Please note:- The installation script needs to write a few temporary files in the current working directory when invoked (they are removed automatically).
- The installation script will not write any files outside the paths you specify except for the temporary files in the current working directory.
If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog:
0 commenti:
Post a Comment