Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: master
Fetching contributors…

Cannot retrieve contributors at this time

file 66 lines (49 sloc) 2.808 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66
== link:index.html[Index] -> link:other.html[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:

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

. 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>.

. <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.
. <em>Forbid</em> will disable caching of
the rule
. <em>Allow</em> will cache whatever <strong>can</strong> be cached.

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

. Content in a SSL/TLS stream.

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

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

. Responses to user petitions requesting specific ranges.

. 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
----
Something went wrong with that request. Please try again.