Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Backports Symfony2 http cache concepts to Symfony 1.4.
Fetching latest commit...
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


Excited by Symfony2 Http Cache but still have heavy load projects to maintain under Symfony 1.4?
Inspired by Symfony2 (concepts and code), this plugin is for you!

isicsHttpCachePlugin fits to our (basic) actual requirements and doesn't already provides all HTTP cache mechanisms. But feel free to contribute!

It comes with :

  • 1 new method for sfWebRequest:
    • getETags()
  • 4 new methods for sfWebResponse:
    • isNotModified(sfWebRequest $request)
    • setETag($etag)
    • setLastModified($date)
    • setMaxAge($duration)
  • ESI support via 2 new helpers:
    • include_component_esi($module_name, $component_name, $vars)
    • include_partial_esi($template_name, $vars)
  • An invalidation method: isicsHttpCacheService::invalidate($url_pattern, $method)

The new methods are unit tested.


We've made a first benchmark with an homepage between 2 versions with exactly the same cache strategy:

  • a classical version using Symfony cache (optimized, 0 SQL queries)

    6 cached components with different TTL and so no cache for action

  • a version using Varnish

    TTL for action and 7 ESI tags (1 userbar without caching and the 6 others with different TTL) Symfony is still called at each request but only for userbar.

The benchmark was made with Siege tool.
It shows a 10 factor between Varnish and Symfony cache (400 req/sec vs 40).


Install the plugin:

$ symfony plugin:install -stability=beta isicsHttpCachePlugin

Enable the plugin in your /config/ProjectConfiguration.class.php:

class ProjectConfiguration extends sfProjectConfiguration
  public function setup()

For ESI support, enable module and helpers in your application(s) settings.yml:

    standard_helpers: [..., isicsHttpCache]
    enabled_modules:  [..., isicsHttpCacheESI]

ESI (Edge Side Includes) support

The new helpers include_component_esi, include_partial_esi are very similar to Symfony ones.

If ESI are enabled (true by default in prod env) and only if a gateway handling ESI is installed (we detect that thanks to a dedicated header), an ESI tag is rendered rather than the content.
Rendering the content is the role of a special action.
Else, the content is direclty rendered exactly like with the Symfony helpers.

As of Symfony2, cache expiration and validation mechanisms are supported.

Both helpers accept an optional cache argument.
The value has a mixed type:

  • For expiration, simply give a duration in seconds:

    <?php include_component_esi('news', 'showLatest', array('limit' => 5, 'cache' => 300)) ?>

    In this example, the latest news component will be refresh every 5 minutes.

  • For validation, the argument value must be a string.

    <?php include_component_esi('news', 'showLatest', array('limit' => 5, 'cache' => 'NewsService') ?>  

    It corresponds to a class name that must defines one or both static methods getLastModified() and getETag():

    static public function getLastModified($vars)
      return NewsPeer::getLastModified();

    and/or :

    static public function getETag($vars)
      return NewsPeer::computeETag();

    Note the $vars argument. It is the vars you passed to the helpers. Use it as you like ;)


The method isicsHttpCachePlugin::invalidate() gives you ability to invalidate one or more url. It uses HTTP BAN and PURGE requests. Prefer PURGE to clear one url cache and BAN to clear many url thanks to regexp.

Note that you have to setup correctly your reverse proxy to handle this requests. For Varnish, you can use those examples:


You can test this tool in CLI with a dedicated task:

  • To clear one url (PURGE method implied):

    $ symfony isics-http-cache:invalidate http://www.mydomain.tld/

    This will clear homepage cache.

  • Or:

    $ symfony isics-http-cache:invalidate --method=BAN http://www.mydomain.tld/.*

    This will clear all the pages under this host.

Custom HTTP headers

The plugin adds custom HTTP headers to ESI components response in order to facilitate granular cache invalidation.

  • x-symfony-viewname : This header can be used to invalidate cache objects when a component / partial template has been modified. Invalidation example (varnish) :

    ban obj.http.x-symfony-viewname == product/someview
  • x-docuri : This header can be used to invalidate cache objects when a document attributes have changed in datastore. Header value is identical to component variable $_docUri. Invalidation example (varnish) :

    ban obj.http.x-docuri == product/123
  • x-guid : This header can be used to invalidate the cache object corresponding to the component / partial currently executed. Header value is identical to component variable $_guid. If it is not set, it is automatically generated using uniqid(). Invalidation example (varnish) :

    ban obj.http.x-guid == the_guid

Varnish admin connection

A class ripped from to ease cache invalidation from PHP:

    $host = sfConfig::get('app_varnish_host');
    $port = sfConfig::get('app_varnish_port');
    $secret = sfConfig::get('app_varnish_secret');
    if ($host == '' || $port == '' || $secret == '')
      throw new Exception('Impossible to configure Varnish Socket! Are you\'re app.yml file well configured?');
    $socket = new VarnishAdminSocket($host, $port);
    $socket->purge('obj.http.x-docuri == myx-docuri-which-goes-well');


A symfony filter can be added in your apps/[apps]/config/filters.yml file between cache and execution filters:

  class: isicsHttpCacheEsiUiFilter


By default, ESI are enabled in prod env. Although, you should have to add the IP of your gateway.

This can be done in your application(s) app.yml:

      enabled:     false
      allowed_ips: []

Varnish configuration

Exactly like Symfony2, you have to setup Varnish to add a particular header telling that ESI are supported:

sub vcl_recv {
    set req.http.Surrogate-Capability = "abc=ESI/1.0";

sub vcl_fetch {
    if (beresp.http.Surrogate-Control ~ "ESI/1.0") {
        set beresp.do_esi = true;    
        unset beresp.http.Surrogate-Control;        

Recommandations ##

  • Do not give large vars to ESI helpers since the vars are serialized and passed to the internal action on the url.

Known issues

  • Slots are broken when using ESI.


  • Try to make ESI render as fast as possible.
  • Write functional tests (not so easy with plugins).
Something went wrong with that request. Please try again.