Cookbook: Redirections

Every now and then a redirection example is requested in the mailing list. This recipe is meant to be a central archive of such examples. Remember there are some more generic examples both in the quickstart and in the redirection handler sections.

There is also a wizard to automatically assist you with redirections. It can be found in the Wizards section of the Virtual Servers panel.

If you are not familiar with how a domain name can be matched, please read about domain matching in Cherokee before proceeding.

Redirections are essential on any modern web server, not only to display pretty URLs, but also to address usability and SEO issues.

A common scenario is that of a virtual server being accessible both with and without the www prefix. It is customary to have both, but it is also a good idea to have only one of them as main entry point to a website, so that the number of web hits isn’t incorrectly halved when anlaysing web traffic.

This can be done on a per-virtual-server basis, but it can be a cumbersome task if we’re dealing with a huge amount of virtual servers.

Of course, Cherokee alows a much more practical approach, and setting up only one rule to handle all redirects is painless and straightforward. Matches can be performed against the host name, the actual request, or both, so the mechanism is quite flexible. If this is what you want, you can jump to the global redirection steps later on this document.

Redirecting to

Sometimes a site will have several domains or subdomains pointing to the same official name. For whatever reasons (site statistics, for instance), having many subdomains redirected to a unique subdomain might be desirable. This can be accomplished fairly easily. The general recipe consists in defining a virtual host with the sole purpose of redirecting petitions to the official subdomain. In our example, this could manage * and the .com and .org variations.

Host Match

Host Match


Domain pattern #1


Domain pattern #2


Domain pattern #3


Host Match interface

The official name would then be managed by another virtual host (just for The redir virtual host will have a Default managed by the Redirection handler.

Rule list

This in turn would define an external redirection with a Regular Expression like ^/(.*)$ and the appropriate Substitution:$1

New Regular Expression

Keep in mind the redirection has to be external in order for Cherokee to rewrite the the URL. If it wasn’t, the redirection would be applied but no change would be displayed to the users while browsing the site.

Redirecting to HTTPS

Now lets imagine a scenario where the name of the virtual server matched is of importance for the substitution. For instance, supose you want all the traffic to the /secure_dir directory of a regular HTTP channel to be redirected to an HTTPS channel through a server whose name depends on that of the matching host.

In this case you need to resort to the macros supported by the handler. First you’ll have to create a Directory type rule managed by the Redirection handler. And second, define an external redirection with a Regular Expression like ^/(.*)$ and the

Handler interface

Global redirections

It is fairly simple to configure a www redirect for every (sub)domain name, where requests of the form must be redirected to

For this you’ll need to:

  1. Create a new virtual server that uses "Regular Expressions" in the "Host Match"

  2. Add a regular expression to match the host names: www\.(.+)$

  3. In the same virtual server, set a "Redirection" handler as the Default rule.

  4. In the handler, add a new RegEx entry defined as follows:

Field Value



Regular Expression




Match parameters


These are substituted by the host name match.


These are substituted by either the handler match (if any) or its own match groups.