In contrast, action composition is intended for route specific concerns, such as authentication and authorisation, caching and so on. If your filter is not one that you want applied to every route, consider using action composition instead, it is far more powerful. And don’t forget that you can create your own action builders that compose your own custom defined sets of actions to each route, to minimise boilerplate.

Let’s understand what’s happening here. The first thing to notice is the signature of the apply method. The first parameter, nextFilter, is a function that takes a request header and produces a result. The second parameter, requestHeader, is the actual request header of the incoming request.

The nextFilter parameter represents the next action in the filter chain. Invoking it will cause the action to be invoked. In most cases you will want to invoke this at some point in your future. You may decide to not invoke it if for some reason you want to block the request.

We save a timestamp before invoking the next filter in the chain. Invoking the next filter returns a CompletionStage<Result> that will redeemed eventually. Take a look at the Handling asynchronous results chapter for more details on asynchronous results. We then manipulate the Result in the future by calling the thenApply method with a closure that takes a Result. We calculate the time it took for the request, log it and send it back to the client in the response headers by calling result.withHeader("Request-Time", "" + requestTime).

The simplest way to use a filter is to provide an implementation of the HttpFilters interface in the root package called Filters. Typically you should extend the DefaultHttpFilters class and pass your filters to the varargs constructor:

If you want to have different filters in different environments, or would prefer not putting this class in the root package, you can configure where Play should find the class by setting play.http.filters in application.conf to the fully qualified class name of the class. For example:

Filters wrap the action after the action has been looked up by the router. This means you cannot use a filter to transform a path, method or query parameter to impact the router. However you can direct the request to a different action by invoking that action directly from the filter, though be aware that this will bypass the rest of the filter chain. If you do need to modify the request before the router is invoked, a better way to do this would be to place your logic in a `HttpRequestHandler` instead.

Since filters are applied after routing is done, it is possible to access routing information from the request, via the attrs map on the RequestHeader. For example, you might want to log the time against the action method. In that case, you might update the filter to look like this:

The key difference here, apart from creating a new EssentialAction to wrap the passed in next action, is when we invoke next, we get back an Accumulator. You could compose this with an Akka Streams Flow using the through method some transformations to the stream if you wished. We then map the result of the iteratee and thus handle it.

Note: Although it may seem that there are two different filter APIs, there is only one, EssentialFilter. The simpler Filter API in the earlier examples extends EssentialFilter, and implements it by creating a new EssentialAction. The passed in callback makes it appear to skip the body parsing by creating a promise for the Result, while the body parsing and the rest of the action are executed asynchronously.