Index → Configuration → Virtual servers

Virtual Server: Rules

Besides the connection handler set for the rule, there are other parameters that can be set in order to customize the rule behavior. This menu offers the following tabs:

Rule: this is the rule type, as explained in the Virtual servers section.
Handler: It allows to fine tune the behavior of any of the available handlers. Since so many options are available, refer to the complete list of handlers shipped with Cherokee.
Encoding: to manage the compression of the contents to be sent.
Expiration: to manage the configuration of HTTP Cache headers used to identify cacheable content.
Security: in this section one can configure Access Restrictions and Authentication.

Encoding

The content sent by Cherokee can be encoded or not. This tab is used to configure, on a per-rule basis, what encoders, if any, are to be applied.

You can set up the encoding method to use, and it shall be applied to whatever content is handled by the parent rule.

Whenever you set up a virtual server, creating a rule where gzip is enabled by default for the following file types: html, htm, txt, css and js is a good idea. You are encouraged to use this. Hardware is cheap. Bandwidth is not.

Expiration

HTTP/1.1 defines caching methods in HTTP. Cherokee-Admin can automatically adjust the Cache-Control and Expire headers depending on the values you have configured. The available options are:

Not set: Does not write the caching headers.
1970: Corresponds to the Unix Epoch.
2038: Maximum date value representable in POSIX time.
Custom Value: set a value by hand.

Access Restrictions

Only https:: This configuration entry determines that the directory will be served by the secure server (https) only. If you access directory /admin -or any sub-directory- throught a non-secure connection Cherokee will report a 426 Upgrade Required error.
Allow From:: This parameter lets you set up wich IP or IP ranges will be allowed to access the directory contents . The remote client IP will be checked with all the provided list and only if the IP matches with some of the rules the access will be allowed.
```
This field accepts a comma separated list of *Host names*, *IP
addresses* or *IP ranges*. In the last two cases, both IPv4 and IPv6
addresses are valid entries.
```

Examples

Allow access only from the IPv6 localhost address
```
   Allow from ::1
```
Allow access from the 127.0.0.0/8 network
```
   Allow from 127.0.0.0/8
```
or it could also we written like
```
   Allow from 127.0.0.0/255.0.0.0
```
It is also possible to use lists instead of a single IP or network range. And there is even the possibility of mixing IPv4 and IPv6 addresses and networks if you want
```
    Allow from 192.168.0.0/16, ::1, 10.0.0.1, 3ffe:3200::/24
```

Authentication

This parameter allows to configure user/password protected entries. A validator has to be used in each Auth entry in order to specify the validaton mechanism. The following validators are available:

plain - Plain text file

Uses a plain flat file to perform HTTP authentication.
htpasswd - Htpasswd file

Uses an htpasswd file to perform HTTP authentication.
htdigest - Htdigest file

Uses an htdigest-generated file to perform HTTP authentication.
ldap - LDAP server

Uses an LDAP directory to perform HTTP authentication.
mysql - MySQL server

Uses a MySQL database to perform HTTP authentication.
PAM - PAM Authentication

Uses PAM to perform HTTP authentication.
Fixed list - Authentication lists

Uses lists of users and passwords to perform HTTP authentication.

It is important to take into consideration that there are two different authentication mechanisms:

Basic
Digest

Some validators can only handle one of those mechanisms because of techical limitations. In case the module supports both of them, the interface allows to choose whether one or both are to be used.