Description: Cherokee is a flexible, very fast, lightweight Web server. It is implemented entirely in C, and has no dependencies beyond a standard C library. It is embeddable and extensible with plug-ins. It supports on-the-fly configuration by reading files or strings, TLS/SSL (via GNUTLS or OpenSSL), virtual hosts, authentication, cache friendly features, PHP, custom error management, and much more.
Keywords: cherokee web server httpd http

## Index → Other information

## Other: Front-line Cache

Cherokee has very sophisticated content caching mechanisms, allowing it to cache anything (static files, dynamic content, etc.). Cherokee’s NEW version 1.2.3 Front-line Cache replaces well known independent front-line caches (i.e., Varnish, Squid, etc.). Independent front-line caches add additional latency to requests due to TCPIP network based round-trips to check whether or not the content has already been cached. With Cherokee, the front-line cache built in so there are is no unnecessary network overhead due to caching.

Front-line cache accelerates HTTP delivery even on content-heavy dynamic websites (see example and notes on caching where cookies exist and how to selectively ignore cookies).

Caching policies can be specified on a per-rule basis. Caching of content is decided by two things:

1. Headers returned by the back-end (i.e., Expires Header).

2. Whatever is specified in the matching rule.

Caching can be customized for each and every rule of your virtual server’s configuration, by specifying any of the three settings available on a per-rule basis in the <tt>Content Caching</tt> section: <em>Leave unset</em>, <em>Allow</em> and <em>Forbid</em>.

1. <em>Leave unset</em> option means that whenever a rule is applied it will not change the status of the caching setting that has been inherited from previously matched rules.

2. <em>Forbid</em> will disable caching of the rule

3. <em>Allow</em> will cache whatever <strong>can</strong> be cached.

Any HTTP content can be cached by Cherokee, except the following:

1. Content in a SSL/TLS stream.

2. Content that is server after having matched an authentication rule.

3. Rules that have set any of the properties No store, No Transform, Must Revalidate, or Proxies Revalidate.

4. Responses to user petitions requesting specific ranges.

5. Responses where the back-end sets a cookie (although you can tell Cherokee to ignore such cookies).

By default, content that includes cookies are not cached, but the setting to allow caching on a rule gives you the ability to disregard cookies using regular expressions (so even that content can be cached).

Cherokee’s rules provide for great flexibility and control over caching. For instance, take the following example where we never cache content from a restricted "members" section of a website, while allowing Cherokee to always cache the contents of another section of the website regardless of presence of cookies, by prepending two rules to the behavior rule list:

    Fullpath: /site/index.php - Non-final - Cache: Disregarded Cookies '.*', Expiration.
    Fullpath: /site/members/index.php - Non-final - Cache: Expiration: 1970