Avoid page caching in AEM through request headers

The Adobe AEM/CQ5 dispatcher is the caching and load balancing tool for AEM/CQ5. This module simply takes the response body from requests made into the AEM instances and saves them as files that then the httpd can deliver.

The dispatcher can be configured to allow requests to be either cached or sent directly to the AEM instance.
By default the Dispatcher configuration is stored in the dispatcher.any text file, though you can change the name and location of this file during installation. The configuration file contains a series of single-valued or multi-valued properties that control the behavior of the Dispatcher.

In general you decide what is cached and what not by defining a set of rules: the keyword “allow” means to cache the page and “deny” not to cache it.

The dispatcher will never cache requests without extension, requests with a query string, non-GET requests and if properly configured requests with an authentication header.

There are several ways of disallowing the dispatcher cache for a page, the one examined in this post avoids caching by sending a specific instruction in the request header of the page.

AVOID PAGE CACHING VIA REQUEST HEADERS

With the Dispatcher release 4.0.0 (and higher) a new header named “Dispatcher: no-cache” is available for page requests. This header informs the dispatcher not to cache the response. The command will then be removed by the dispatcher before forwarding the response to the client.

In AEM in order to disable caching in the dispatcher via request headers, you need to add the header “Dispatcher: no-cache”. So for instance you can add the following code in your JSP:

<%
 response.setHeader("Dispatcher", "no-cache");
%>
 As of today, Sightly does not support a direct implementation of this command.

As of today, Sightly does not support a direct implementation of this command.

There are two ways you can achieve this. The first is a workaround which consists in creating a small JSP script with the command seen previously and include it as a sly command in page:

<sly data-sly-include="no-cache.jsp" />

The second approach requires a bit more of effort but results in a more clean solution and consists in using an API routine which can provide a JavaScript interface for accessing and manipulating the request part of the HTTP.
There exists some already developed API with these features such as Fetch API or it can be developed internally since it could be a very wide used approach throughout projects.
The Sightly command in this case would become:

<sly data-sly-use="<api-path>" />

With “api-path” enabling the usage of the JS API defined and a JS Script in the page activating the request header.

CONSIDERATIONS

Dispatcher default policies avoid caching of dynamic pages automatically.
Anyhow it may be necessary to extend those rules to pages that normally would be cached. This is possible by setting the rules inside dispatcher.any file buta more flexible and agile solution can be achieved following the technique described in this article.

In fact, the request header approach allows to reason in terms of page/template, or even components (for instance, a specific component dragged in a page may trigger the no cache directive) and hence to define a set of dynamic pages without any considerations in terms of paths or locations.