This backend works in concert with Zend_Cache_Frontend_Capture (the two must be used together) to save the output from requests as static files. This means the static files are served directly on subsequent requests without any involvement of PHP or Zend Framework at all.

The benefits of this cache include a large throughput increase since all subsequent requests return the static file and don't need any dynamic processing. Of course this also has some disadvantages. The only way to retry the dynamic request is to purge the cached file from elsewhere in the application (or via a cronjob if timed). It is also restricted to single-server applications where only one filesystem is used. Nevertheless, it can be a powerful means of getting more performance without incurring the cost of a proxy on single machines.

Before describing its options, you should note this needs some changes to the default .htaccess file in order for requests to be directed to the static files if they exist. Here's an example of a simple application caching some content, including two specific feeds which need additional treatment to serve a correct Content-Type header:

AddType application/rss+xml .xml
AddType application/atom+xml .xml

RewriteEngine On

RewriteCond %{REQUEST_URI} feed/rss$
RewriteCond %{DOCUMENT_ROOT}/cached/%{REQUEST_URI}.xml -f
RewriteRule .* cached/%{REQUEST_URI}.xml [L,T=application/rss+xml]

RewriteCond %{REQUEST_URI} feed/atom$
RewriteCond %{DOCUMENT_ROOT}/cached/%{REQUEST_URI}.xml -f
RewriteRule .* cached/%{REQUEST_URI}.xml [L,T=application/atom+xml]

RewriteCond %{DOCUMENT_ROOT}/cached/index.html -f
RewriteRule ^/*$ cached/index.html [L]
RewriteCond %{DOCUMENT_ROOT}/cached/%{REQUEST_URI}.(html|xml|json|opml|svg) -f
RewriteRule .* cached/%{REQUEST_URI}.%1 [L]

RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]

RewriteRule ^.*$ index.php [NC,L]

The above assumes static files are cached to the directory ./public/cached. We'll cover the option setting this location, "public_dir", below.

Due to the nature of static file caching, the backend class offers two additional methods: remove() and removeRecursively(). Both accept a request URI, which when mapped to the "public_dir" where static files are cached, and has a pre-stored extension appended, provides the name of either a static file to delete, or a directory path to delete recursively. Due to the restraints of Zend_Cache_Backend_Interface, all other methods such as save() accept an ID which is calculated by applying bin2hex() to a request URI.

Given the level at which static caching operates, static file caching is addressed for simpler use with the Zend_Controller_Action_Helper_Cache action helper. This helper assists in setting which actions of a controller to cache, with what tags, and with which extension. It also offers methods for purging the cache by request URI or tag. Static file caching is also assisted by Zend_Cache_Manager which includes pre-configured configuration templates for a static cache (as Zend_Cache_Manager::PAGECACHE or "page"). The defaults therein can be configured as needed to set up a "public_dir" location for caching, etc.