Response caching

An action response of any type (HTML or JSON, for example) may be cached in the client in order to improve performance. Needless to say, this should only happen if the result that it is returning rarely changes. This is specified in RFC 7234, HTTP/1.1 Caching (https://tools.ietf.org/html/rfc7234).

Essentially, response caching is a mechanism by which the server notifies the client (the browser or a client API) to keep the response returned (including headers) for a URL for a certain amount of time and to use it, during that time, for all subsequent invocations of the URL. Only the GET HTTP verb can be cached, as it is designed to be idempotent: PUT, POST, PATCH, or DELETE cannot be cached.

We add support for resource caching in ConfigureServices as follows:

services.AddResponseCaching();

We use it in Configure, which basically adds the response caching middleware to the ASP.NET Core pipeline:

app.UseResponseCaching();

We can also set a couple of options in the call to AddResponseCaching, such as the following:

• MaximumBodySize (int): This is the maximum size of the response that can be stored in the client response cache; the default is 64 KB.
• UseCaseSensitivePaths (bool): This enables you to configure the request URL for the caching key as case-sensitive or not; the default is false.

These can be used using an overload of the AddResponseCaching method:

services.AddResponseCaching(options =>
{
    options.MaximumBodySize *= 2;
    options.UseCaseSensitivePaths = true;
});

We can also have an action result cached by applying the [ResponseCache] attribute to either the action or the whole controller class. Following this, we have a couple of options—we can either specify each of the cache parameters directly in the attribute or we can tell it to use a cache profile.

The options are as follows:

• Duration (int): The number of seconds to cache; the default is 0
• Location (ResponseCacheDuration): The location of the cache (Client, None, Any); the default is Any
• NoStore (bool): Whether to prevent the storing of the result; the default is false

• VaryByHeader (string): The comma-separated list of headers for which an instance of the result is cached; the default is null
• VaryByQueryKeys (string []): A list of query string parameters for which an instance of the result is cached; the default is null
• CacheProfileName (string): The cache profile name, which is incompatible with the other options; the default is null

As we have mentioned, you either specify all of the individual options (or at least those that you need) or you specify a cache profile name. Cache profiles are defined at Startup in the ConfigureServices method through the AddMvc extension method, as follows:

services.AddMvc(options =>
{
    options.CacheProfiles.Add("5minutes", new CacheProfile
    {
        Duration = 5 * 60,
        Location = ResponseCacheLocation.Any,
        VaryByHeader = "Accept-Language"
    });
});

This cache profile specifies that results are kept for five minutes, with different instances for different values of the Accept-Language header. After this, you only need to specify the name 5minutes:

[ResponseCache(CacheProfileName = "5minutes")]
public IActionResult Cache() { ... }

The VaryByHeader and VaryByQueryKeys properties, if they have values, will keep different instances of the same cached response for each value of either the request header or the query string parameter (or both). For example, if your application supports multiple languages and you use the Accept-Language HTTP header to indicate which language should be served, the results are kept in cache for each of the requested languages—one for pt-PT, one for en-GB, and so on.

It's generally preferable to use cache profiles, rather than providing all parameters in the attribute.

Let's now see how we can maintain the state between subsequent requests.