Skip to content

Caching

Caching Modes

A caching policy must be decided: the goal is to cache as many responses as possible (to increase efficiency), but never do so when it is not allowed (to avoid breaking site functionality).

In the default mode, the Web Accelerator follows the normal HTTP semantics. This mode is usually not useful, at least without a customized configuration, because HTTP forbids caching responses that receive or emit cookies and generally all requests have them.

"Standard" caching: as an evolution of the precedent method, cookies can be ignored for objects that are presumed to be static, and thus force caching them: images, CSS, Javascript, fonts, etc. A configuration of this type works with no customization, but it does not cache dynamic pages and consequently does not allow for the best performance.

"Forced" caching: caching is done for all objects except those explicitly excluded, such as the administrative area of the site or the shopping cart. It requires detailed knowledge of the CMS or specific site operation, but an accurate configuration enables optimal caching. The Web Accelerator automatically handles the most common cases thanks to a library of ready-made configuration modules for the most popular CMS like Wordpress, Joomla, and Magento.

It is also possible to use more complex URL criteria to exclude something from caching: for example, the Web Accelerator can examine cookies to determine if a request was made by an authenticated user, who should therefore receive a customized page.

Additionally, the information contained in cookies can be used to partition the cache and have different versions of the same page customized according to features such as language, currency, or even each authenticated user.

It is understood that normally caching is only done for responses to requests with the HTTP GET or HEAD methods.

TTL of Cached Objects

The Web Accelerator caches objects for the time specified by the Cache-Control headers sent by the backend, up to a maximum duration (default: 1 day).

In the absence of the header, a default TTL is applied based on the file extension in the URL: for assumed static objects (images, CSS, Javascript, fonts, etc.) this value is 1 hour, while for assumed dynamic pages (i.e., everything else) it is 5 minutes. Redirects 302 and 307 and errors 403 and 404 are cached for 1 minute instead.

If the backend cannot send appropriate Cache-Control headers, it is still possible to configure customized policies on the Web Accelerator with the greatest granularity. Our staff is available to evaluate the best settings for each site.

If the backend is faulty and it is not possible to update the cache, the Web Accelerator will respond with expired objects up to one hour before.

Therefore, it is emphasized that if the backend sends objects with headers like Cache-Control: no-cache, it will prevent caching: in this case, if it is not possible to fix these headers, the Web Accelerator can be configured to completely ignore them.

Cache Invalidation

There are three different APIs available to invalidate the cache content:

  • Requests for specific objects with the HTTP PURGE method.
  • Objects corresponding to a regular expression requested with the HTTP PURGE method, adding an X-Purge-Method: regex header.
  • The Drupal invalidation API, wit no need to set X-Varnish-Secret.

Requests are only accepted from the backend IP address, or eventually from others configured to be authorized. PURGE requests can be made indifferently using HTTP or HTTPS, while BAN requests must be made using HTTPS.

To automatically manage invalidation in Wordpress, it is possible to install a plugin that implements one of these interfaces, for example Proxy Cache Purge.

A sample file test_purge.php is available, showing how to invalidate an object with PHP and libcurl.

Temporarily Disabling Caching

During development activities that directly involve the production site, it is possible to disable caching for the current browser session by accessing https://<domain>/seeweb-wa/cache-bypass.

Informative Headers

Varnish responses contain these headers that allow understanding where the object comes from:

x-varnish: 5217771 2207419
age: 261

If X-Varnish contains two numbers, it means the response comes from the cache, while if it contains only one, it means it comes from the backend.

The Age header indicates the age in seconds of the response object.