IndexConfiguration

Virtual Server

Virtual Server is an abstraction mechanism that allows you to define a custom number of parameters and rules that have to be applied to one or more domains.

In a Cherokee server there must be at least one virtual server named default, and there is no maximum number. It is important to know that this server cannot be deleted.

When the server receives a request it will try to match the domain name specified in the virtual server that should handle it. In case no virtual server matches the request, default will be used.

Three main options are accessible through this menu:

  1. Virtual Server List

  2. Add new Virtual Server

  3. Clone Virtual Server

Cloning a Virtual Server is simply a matter of selecting a target name and a source virtual server currently present. Every setting will be duplicated. From then onwards changes applied to any of them, be it the original or the copied Virtual Servers, will only apply to the implicated one. This is a great way to set up complex domains, since you can use the existing ones as templates to be refined with further work.

To add a new Virtual Server you have to enter the server name and a valid Document Root directory.

Virtual server

The Virtual Server List is by far the most interesting of these three main options. It gives an overview of the existing virtual servers, and allows to configure in detail every possible setting.

Virtual server overview

A detailed explanation of every tab follows.

Basics

Domain names

This section allows to define the list of domains that the virtual server implements.

It can accepted either FQDN (Fully Qualified Domain Names) or wild card entries.

For instance
          example.com
        *.example.org

Behavior

This sections allows to define a set of rules to define how the server should handle the different requests. A summary of the existing rules is presented, containig several fields of information:

  1. Target: web target of the rule, be it a path, a file type, etc.

  2. Type: Rule type. The will be explained in the following paragraphs.

  3. Handler: The handler that manages the requests that match this rule. Read on for further details.

  4. Auth: Indicates if authentication is used for this rule. This can be set up through the Rule Entry menu.

  5. Final: If this flag is present it means that no other rules will be applied after this one, even if the request also matches other rules with lower priority.

These rules can be defined based on the directory that the request targets, the extension of the file that it is requesting, or a regular expression that may match the request. This is the list of available rule types:

It is very important to know that these rules are prioritized. The higher its priority is, the sooner they are checked. You could think of a network routing table, it is quite similar. You can set the relative priorities among the rules by simply dragging and dropping them in the desired position (if you click on the rule name, you will be redirected to the rule's configuration options; if you click anywhere else, you will be able to drag and drop it into the desired position).

Virtual server

Each of these behavior rules must specify which is the handler that the server should use to reply to the requests that match the rule. Handlers are the modules that generate the information with which the server responds a client's request. By default Cherokee provides a number of them:

The selection of any one of the rule targets will offer new configuration options through the Rule Entry menu.

Each of the mentioned handlers can be fine-tuned through that menu. Refer to each handler's documentation if you are interested in the available settings.

Personal Webs

This options allows to setup the name of a subdirectory inside the users' home directory that will be used as document root for personal web content. For instance, if /foo was specified, a user bar could publish the content of /foo at the relative URL /bar This option is disabled if the Directory name field is empty.

Error Handler

Several mechanisms exist to handle errors.

  1. Default errors

  2. Custom redirections

  3. Closest match

Using the Custom redirections error handler we can easily redirect errors to a custom path or website.

Virtual server

The Closest match error handler should never fail to deliver something. If a requested resource is not available, the closest match will be sent. The only exception to this is when nothing at all is at Cherokee's disposal, in which case a standard http error is sent.

Logging

The loggers are a type of Cherokee modules to write the server log information using different destinations and/or formats:

If a virtual server doesn't have a logger set up it will not log anything.

Virtual server

By default Cherokee ships three loggers implementing three different logging formats:

Security

The virtual server must be configured with the path to the certificate before using secure connections (https). There is a document which might help to generate SSL keys