Roxen Challenger HTTP Web Server

The Roxen Challenger HTTP Web Server is a marvel ahead of its time. That's a bold, hard-to-prove statement for a web server when compared to the amazing success of the Apache HTTP Server. Before you stop reading, you should consider that there is nothing wrong with having two subtly different, yet very good tools.

Apache is designed from the ground up to be a simple, open, secure, high-performance HTTP server, and it pays up in spades. Apache is the natural choice for almost all web administrators weaned on NCSA CERN or a commercial HTTP server like Netscape. However, Apache is not exactly intuitive to configure, the configuration in question being three flat text files. Apache also suffers from a monolithic structure (albeit plug-in modularity is a new option if you compile it in) which requires recompiling the source code when making changes or adding modules (such as proxy, database access, etc.).

Roxen takes a different approach to HTTP server design. Roxen is easily installed and configured. The user need only do the normal ./configure and make sequences after unpacking the tar file and reading the README file. This has worked flawlessly a dozen times for me on Intel Red Hat 4.2 and 5.0 machines. After compiling the Pike interpreter (we'll get to that), the installation script tells you to point your browser to http://localhost:x/, x being some random unassigned port where the configuration interface server listens for your browser.

Pointing a browser to that URL brings up the on-line, web-centric configuration interface. The first screen sets the configuration, user and password information for subsequent configuration sessions. Immediately, virtual servers can be added, and adding a virtual server is a snap. My usual sequence is to find a free IP and bind the hostname.domain to it. Next, I create the aliased Ethernet interface with netcfg specifying the chosen IP. I switch to the Roxen configuration interface, and using simple, point-and-click menus, add a new server binding it to the interface just created. Roxen automatically detects this and does a reverse lookup for me. Voilá--I have an instant virtual server. The whole process took less time than making a cup of coffee.

When creating the server, Roxen asks questions about the kind of server desired. The choices consist of Bare Bones, Standard, IPP (Internet Presence Provider), Proxy or a copy of the configurations for any current servers in the system. This gives lots of flexibility when working with more than just a few virtual servers.

Each of the four choices is a certain set of loaded modules for each server. Modules can be mixed and matched to make custom servers. Modules, also written in Pike, can be loaded and unloaded on the fly, and all modules have a standard configuration interface that plugs into the server configuration interface. Modules include the file system, authentication, database access, CGI and FCGI execution, on-the-fly graphics manipulation and more.

So how is this marvelous server put together? Roxen is written in the Pike language. Pike is an interpreted, threaded, C-like language based on an older programming language for MUD systems. Pike is fully developed and has a graceful, clean style so much like C that any C programmer can pick it up in minutes. This makes writing custom Roxen modules a snap. Pike's home page has excellent, intelligently written documentation that is completely cross-referenced and includes a handy function index where many old familiar buddies from the ANSI C libraries can be found.

The downside is that Pike, being a byte code interpreted language, is slower than compiled and optimized C by a noticeable margin. Roxen 1.1 is also a bit buggy, and Roxen 1.2 is still in beta. Having dabbled in 1.2 (which installed just as cleanly as 1.1), I found it very cool with many new modules, some of which are not available for Apache, such as on-the-fly wizard generators and automatic table formatting of SQL-retrieved data. A new update module contacts the Roxen central server in Sweden and upgrades the server and all the modules to the newest debugged versions, and offers to download any new modules Idonex has created as well. 1.2 also uses the new threading built into the latest version of Pike, increasing its performance for high or eccentric load systems and allowing it to take advantage of multiprocessor systems.

The most powerful module in the Roxen set is the Roxen Markup Language (RXML). RXML looks like HTML, and it is written directly into the HTML code. When a client retrieves a document from the server, the server first parses the document for RXML tags, changing the HTML output based on the tags used. This is basically server-side scripting with server-side includes in Apache parlance, but cleaner. For example:

<html>
<head>
<body>
<if user=jane>
<gtext scale=0.5 nfont="arial" fg="blue"
bg="white">Hi there Jane.</gtext><br>
<else>
<h1>Hey get outta here!</h1>
</if>
</body></head></html>

The <if><else></if> construct outputs different HTML depending on whether the client fetching the page has authenticated itself as the user jane. The <gtext> tag takes the text and renders a gif image of it on the fly, replacing the <gtext> tag with an <img> tag whose src is the generated image. Many options to gtext are available, including transparency, sizes, bevels, automatic Javascript mouse responses and more. Check out Roxen's home page for an example, or the American Association for the Surgery of Trauma web page, where I used gtext and RXML extensively.

Roxen's extreme ease of use and modularity make it a powerful tool for web managers of all needs. The GNU GPL license for Roxen and Pike makes the price just right. Like all good GPL software, Pike and Roxen are backed by an active, sharp Internet crowd of Pike programmers and Roxen-heads eager to help you with your questions. Idonex also offers various levels of support for very reasonable prices. The Roxen Server comes pre-packaged with a manual and other non-GPL goodies (like 128-bit SSL) from Idonex.

Resources

This article was first published in Issue 31 of LinuxGazette.com, an on-line e-zine formerly published by Linux Journal.