Caudium 1.0, 1.2, 1.3

For those of you currently running Apache that are considering moving to Caudium, there are some things that Caudium does differently than Apache. We've tried to present a list of known issues dealing with conversions from Apache to Caudium so that you can be aware of things that may crop up while migrating.

• Server Side Includes & Caudium
• .htaccess differences
• mod_rewrite functionality
• Error 404 handling
• Virtual Hosting Support on a single IP
• PHP Support
• CGI Support/Path Info
• Logging differences
• SSL Support

At some point you will need to enable Server Side Includes on your Caudium Installation. In the Configuration Interface, click on the module Core RXML Tags, click on SSI Support, and change the Execute Command GID and UID if needed. By default, the execute command is turned off.

Now, in the upper section, click on your Server Name, click on Main RXML Parser or XML-Compliant RXML Parser and ensure that .shtml is listed in the Extensions to parse.

There are other commands that are commonly used through server side includes that can be handled differently and more efficiently through Caudium. This table illustrates some of the equivalent commands in RXML:

Apache   Caudium   Using SSI to display a date   <date> tag.   Using JavaScript to display a date   The <date> tag actually is parsed by the server whereas JavaScript is parsed by the client. Search Engines do not parse JavaScript, and therefore your JavaScript Date would not be recognized by the Search Engine.   Using SSI to include files for templating   Caudium has the <use> and <insert> tags which can be much more powerful than simply including a file through SSI. Caudium also caches the template files for faster execution and page serving.   SSI and exec cmd   Because of the way Caudium works, you may need to specify the full file path for exec cmd SSI statements.   Using SSI for URL Based session tracking   The GSession and 123Sessions module both provide easy to use session tracking based on url or cookies. The result is a cleaner URL for hosts that accept cookies. GSession was engineered to be much more search engine friendly than 123Sessions, but maintains backwards compatibility and is an easy drop-in replacement.   Using JavaScript for Client capabilities detection   Caudium contains the supports database, which is passed through to CGI scripts and can be accessed within RXML quite easily to make decisions based on Client capabilities.   SSI to include events based on time schedules   One can write a module that includes content based on certain filters, or use the RXML <if> statements to display content based on dates, times, variables, etc.

Caudium supports the NCSA Standards for .htaccess file construction. As a result, any .htaccess that works in Apache, may not work in Caudium. Usually this involves adding <limit GET POST PUT> and </limit> around the require valid-user statement in the .htaccess.

Complete NCSA Specifications for .htaccess are available here.

Along with that, Caudium has a few built in authentication methods so that the .htaccess file is not as necessary. Authentication from MySQL/PostgreSQL and a number of other supported databases can be done without needing .htaccess files.

When moving from Apache, mod_rewrite is the proverbial swiss army knife for URL manipulation. While that is the case, 95% of the uses for mod_rewrite have been handled with two modules that are included within the base distribution of Caudium.

The first module is the ReferrerDeny module. This module blocks access to images based on the referrer sent by the remote client. Typically this is called 'hotlink' protection.

The second module is the BrowserDeny module. This module blocks access to files based on the UserAgent of the remote client. It is common to block automated site suckers, email address surfing software, etc.

If you need more complex rewriting of URLs, Caudium has the Rewrite module. This module doesn't have support for multi-line rules like mod_rewrite, but does contain a number of advanced features that sometimes surpass mod_rewrite's capabilities.

If the above solutions don't work, you can always write a custom module to handle your specific requirements, but in general, the first two modules will probably address 95% of the issues you might run into while converting your site.

There are many ways to handle Errors in Apache, and just as many different ways to handle it in Caudium. There is an excellent error Theme system in the base installation of caudium that provides debugging, multiple levels of detail on the errors while maintaining a nice consistent look.

You can use either 404.pike which will allow you to redirect 404 traffic to an external site or 404file.pike which will allow you to present a page that is parsed but not redirected. These modules would be similar to:

ErrorDocument 404 http://domain.com/url.html
and
ErrorDocument 404 /index.html
respectively.

To enable Virtual Hosting in Caudium, setup is a little different than in Apache. First you set up a main server that will handle the requests and set up a regexp so that the other sites are able to be matched. The Regexp in the Virtual Host Matcher would be specified as:
.*\.domain.com|^domain.com$ domain.com
Setup within the virtual site is done by setting the URLs and not having to set an IP to listen to.

While there is PHP support in Caudium, you may find that RXML can do many of the things that you would use PHP for, and in many cases can provide an easier interface for certain functions. Creating tables from SQL output in Caudium is much easier than using PHP. However, for applications that need to be moved over, Caudium does support PHP.

Caudium provides full support for CGI scripts, and passes the supports database information to the script as well. So your scripts can take advantage of the supports functionality which will allow you to add extra capabilities to your scripts.

It is also very easy to write MODULE_LOCATIONs that are similar to .cgi scripts, but are resident and become part of the Caudium Server.

If you use a web log analyzer, the default format in Caudium may not be what you are looking for. Rotation of logs is a bit different too as you can specify the filename to log to with certain macros. If you want to change the log format, within the Configuration Interface for your server, click on, Configuration Interface, Server Variables, Logging, Format.

You may want to use the following format string which replicates the combined logging format from apache.

*: $host - $user [$cern_date] "$method $resource $protocol" $response $length "$referer" "$agent_unquoted"

Log file names can also be specified in the configuration interface. To maintain similar log file rotation as apache, you don't need to change the name. If you want to use a separate log file for each day, you can specify the log file name with an extension of .%y%m%d and it will create a new log file each day with a yyyymmdd extension.

SSL Support is done through the Configuration Interface. A document to help describe this process is available here