Response processors


A response processor is a special filter that only runs at response time, earlier than other filters in the pipeline.

Consider using regular HTTP Filters as an alternative if you are not planning to use page contributions.


Response processors are executed after the post processing steps, and before the contributions filter in the site engine pipeline.

Common use cases for response processors are:

  • Dynamically adding page contributions (i.e. script tags)

  • Manipulation of the response i.e. headers or body


To create a page processor, simply place a controller file in you project folder src/main/resources/site/processors i.e. src/main/resources/site/processors/myprocessor.js

The controller must export a responseProcessor. The export receives the request and response objects as parameters and must return a response object as done in HTTP Controllers.

Below is an example that dynamically adds a bodyEnd page contribution to the response.

exports.responseProcessor = function (req, res) {
    var trackingScript = '<script src="http://some.cdn/js/tracker.js"></script>';

    // Check if contribution field exists, if not create it
    var bodyEnd = res.pageContributions.bodyEnd;
    if (!bodyEnd) {
        res.pageContributions.bodyEnd = [];

    // Add contribution

    return res;


In order to actually be executed, the processor must be declared in the app’s site descriptor:

    <response-processor name="tracker" order="10"/> (1) (2)
1 @name indicates name of the controller file
2 @order indicates execution order, as described below

Response processors may change any of the values of the response object, that includes: HTTP status code, response body, HTTP headers, cookies and page contributions. It is also possible to return the response object received without any changes.

Execution order

An application may contain multiple processors. Multiple applications can be added to a Site. When a page is rendered, all processors are ordered and executed accordingly.

The order of execution is determined by the order value (as defined in the site descriptor) combined with the order of the application list within the site.

Processors with a lower order will be executed first (across all apps within the site). In case there are several filters with the same order number, the position of the applications (as configured on the site) determines the order of execution.

If applyFilters is set to false in the response object, the response processing will be stopped. Default value is true.