docs.roxen.comView this page in a printer friendly mode
DocsRoxenWebServer 4.5Web Developer ManualRoxen Concepts
Copyright  2012, Roxen Internet Software
Suggestions, comments & compliments

RXML Evaluation
URL Extensions

URL Extensions

Since everything after the host part of the URL is sent to the server as is, after transport encoding, the server in practice decides the meaning of that part of the URL. Normally that part of the URL consists of a path part, containing the path to a file the client wants, and a query part, containing variables that may affect the way the server accomplishes the request.

In the URL above we request the file /products/platform/tech-features.xml from the host with the variable page set to 9. Note that there is in principle nothing that prevents us from making a server that returns the same result with the following URL.

This is however not a good idea for several reasons, usability being the number one. Users are used to alter the URL of a page to get to index-pages higher up in the web site structure.

Index pages

The most common sidestep from the rule that the path part of the URL explicitly denotes a file is directory URLs.

The above URL does not denotes a specific file in the /products/platform/ directory, but does instead point at the directory itself. The common approach is to find an index file in the directory and send that file instead. This is handled by the directory module, which by default looks for the files "index.html", "index.xml", "index.htm", "index.pike" and "index.cgi" in that order.

Path info

Sometimes it can be practical to fake a directory structure, but let all requests to the files in that directory lead to the same file. The example with the tech-features.xml URL above could look like this:

The part of the URL after the actual file will then be provided to the file/script in a special variable during its parsing.


When developing and debugging is a great help to be able to turn on and off specific parts of the code that generates the current page. This is an ideal application for prestates, a mechanism invented by Roxen to enable the user to turn certain switches on and off. The name and function of the prestates is decided by the page developer. One example of how prestates are used is the Table/Image Border Unveiler module, which is used on the web site.

This URL signifies that we want to fetch file at the path /developers/ from the host with the protocol HTTP and with the prestate tables set. In the WebServer the Table/Image Border Unveiler module recognizes the table prestate and knows that the user wants all tables highlighted in the page. Compare the result with how the page look without the prestate. It is also possible to add several prestates to the same page in a comma separated list, e.g.,images)/developers/

Prestates can of course be used for many other things than switching debugging flags, e.g. moving states between pages like a browser window local cookie. See <apre> and <if prestate> for more information about how to control and detect prestates in your RXML applications.

Config states

A variation of prestates is the config state. Looks very similar to the prestates, but stores its value in a cookie. Looking at the following URL will store the value "bacon" in the cookie RoxenConfig, which will be valid for two years since its latest change. After the cookie has been set, the server will redirect to the page you came from, or it it was unable to determine that page, to the same URL but without the config state.<bacon>/

Removing a config state value is a little trickier than with prestates, since you can not edit them by hand, as with the URL. Prepending a minus sign before a config state flag indicates that it should be removed from the RoxenConfig cookie. As with prestates it is possible to combine several states at the same time, both with and without minus signs.<egg,-bacon>/

See <aconf> and <if config> for more information about how to control and detect config stats in your RXML applications.