Varying Caching Using Headers

The simplest form of caching variation is to deliver different versions of cached content based on the headers in the HTTP request. To demonstrate how this works, I have modified configuration of the OutputCache applied to the Index action method on the Home controller, as shown in Listing 12-6.

Listing 12-6.  Varying Cached Content Based on Headers in the HomeController.cs File

using System.Diagnostics;
using System.Threading;
using System.Web.Mvc;
using System.Web.UI;
using ContentCache.Infrastructure;
 
namespace ContentCache.Controllers {
    public class HomeController : Controller {
 
        [OutputCache(Duration = 30, VaryByHeader="user-agent",
            Location = OutputCacheLocation.Any)]
        public ActionResult Index() {
            Thread.Sleep(1000);
            int counterValue = AppStateHelper.IncrementAndGet(
                AppStateKeys.INDEX_COUNTER);
            Debug.WriteLine(string.Format("INDEX_COUNTER: {0}", counterValue));
            return View(counterValue);
        }
    }
}

The VaryByHeader property of the OutputCache attribute allows me to specify one or more headers that will be used to differentiate between requests. I selected the easiest header to test, which is User-Agent, used to identify the browser (and which is used by the browser capabilities feature that I described in Chapter 7).

The ASP.NET platform will execute the Index action method and cache the result for every different user-agent header value that it receives. Subsequent requests that contain the same user-agent header within the caching direction will receive the appropriate cached version.

You will need two different browsers to be able to test this example, such as Internet Explorer and Google Chrome. Start the application and navigate to /Home/Index with both browsers. You will see a different counter value for each browser, which reflects the fact that different content has been cached for each user-agent value.

Varying Caching Using Form or Query String Data

A similar approach can be taken to generate and cache content for different permutations of form or query string data. Of all the techniques I describe in the chapter, this is the one that requires the most caution and causes the most trouble. In most web applications, it is important that data sent from the user is processed and used to update the model, advancing the user through the application flows and features. Caching content based on form data can mean that user interactions don’t target the action methods in the application, which means that user input is lost. That said, this technique can be useful if you have action methods that generate content without updating the model—although if this is the case, static HTML can often be a better alternative than caching content generated by an action method. Listing 12-7 shows how I have updated the Home controller so that the content generated from the Index action method is varied based on user data values.

Listing 12-7.  Varying Cached Content Based on User Data in the HomeController.cs File

using System.Diagnostics;
using System.Threading;
using System.Web.Mvc;
using System.Web.UI;
using ContentCache.Infrastructure;
 
namespace ContentCache.Controllers {
    public class HomeController : Controller {
 
        [OutputCache(Duration = 30, VaryByHeader="user-agent",
            VaryByParam="name;city", Location = OutputCacheLocation.Any)]
        public ActionResult Index() {
            Thread.Sleep(1000);
            int counterValue = AppStateHelper.IncrementAndGet(
                AppStateKeys.INDEX_COUNTER);
            Debug.WriteLine(string.Format("INDEX_COUNTER: {0}", counterValue));
            return View(counterValue);
        }
    }
}

The VaryByParam property is used to specify one or more query string or form data parameter names. For each permutation of values of these parameters, ASP.NET will cache a version of the content generated by the action method and use it to satisfy subsequent requests made with the same values.

To see the effect, start the application and navigate to the following URL, which contains query string values for the parameters specified for the VaryByParam property:

/Home/Index?name=Adam&city=London

Open a second instance of the same browser and request the same URL, and you will receive the cached content from the previous request. If you specify a different name or city, then a new version of the content will be generated and cached.

In Listing 12-7, I left the VaryByHeader property set, which means that different versions of the content will be cached for every permutation of query string values and user agents that ASP.NET receives requests for. This means that requesting the URL shown earlier from Internet Explorer and Google Chrome, for example, will generate different versions of the cached content, even though the query string values are the same.

Creating Custom Cache Variations

You can create custom caching variations if headers and user data are not enough to differentiate between the requests that your application receives. The OutputCache.VaryByCustom property is used to specify an argument that is passed to a method in the global application class, which is called when requests are received to generate a cache key. Listing 12-8 shows the application of this property in the Home controller.

Listing 12-8.  Using a Custom Cache Variation in the HomeController.cs File

using System.Diagnostics;
using System.Threading;
using System.Web.Mvc;
using System.Web.UI;
using ContentCache.Infrastructure;
 
namespace ContentCache.Controllers {
    public class HomeController : Controller {
 
        [OutputCache(Duration = 30,
            VaryByHeader="user-agent",
            VaryByParam="name;city",
            VaryByCustom="mobile",
            Location = OutputCacheLocation.Any)]
        public ActionResult Index() {
            Thread.Sleep(1000);
            int counterValue = AppStateHelper.IncrementAndGet(
                AppStateKeys.INDEX_COUNTER);
            Debug.WriteLine(string.Format("INDEX_COUNTER: {0}", counterValue));
            return View(counterValue);
        }
    }
}

I specified the value mobile, which I’ll use to identify mobile devices using the capabilities detection feature that I described in Chapter 7. As I explained in Chapter 7, there are some serious hazards when it comes to detecting mobile devices because the term is so nebulous and the data quality is so low, but it is good enough for my purposes in this chapter. Listing 12-9 shows how I have added support for the mobile cache variation in the global application class.

Listing 12-9.  Adding a Custom Cache Variation to the Global.asax.cs File

using System.Web;
using System.Web.Mvc;
using System.Web.Routing;
 
namespace ContentCache {
 
    public class MvcApplication : System.Web.HttpApplication {
 
        protected void Application_Start() {
            AreaRegistration.RegisterAllAreas();
            RouteConfig.RegisterRoutes(RouteTable.Routes);
        }
 
        public override string GetVaryByCustomString(HttpContext ctx, string custom) {
            if (custom == "mobile") {
                return Request.Browser.IsMobileDevice.ToString();
            } else {
                return base.GetVaryByCustomString(ctx, custom);
            }
        }
    }
}

HttpApplication, which is the base for the global application class, defines the GetVaryByCustomString method. To add support for a custom cache variation, I override this method and check the value of the custom argument. When this argument is mobile, I am being asked to generate my custom cache key from the request, which I do by returning the value of the HttpRequest.Browser.IsMobileDevice property. This means I will cause two variations of the data in the cache—one for devices that cause the IsMobileDevice property to return true and one for those that return false. I call the base implementation of the method for all other values of the custom argument, without which the other variation features won’t work.

Creating Cache Profiles

As Listing 12-8 shows, the configuration of the OutputCache attribute can be verbose and is required for any action method or controller class for which caching is required. To help reduce duplication and to ensure consistent caching policies, the ASP.NET platform supports cache profiles. A cache profile is a particular caching configuration defined in the Web.config file that can be applied anywhere in the application by name. Listing 12-10 shows how I created a cache profile for the example application.

Listing 12-10.  Creating Cache Profiles in the Web.config File

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings>
    <add key="webpages:Version" value="3.0.0.0" />
    <add key="webpages:Enabled" value="false" />
     <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />
  </appSettings>
  <system.web>
    <compilation debug="true" targetFramework="4.5.1" />
    <httpRuntime targetFramework="4.5.1" />
    <caching>
      <outputCacheSettings>
        <outputCacheProfiles>
          <add name="cp1" duration="30" location="Any"
               varyByHeader="user-agent" varyByParam="name;city" varyByCustom="mobile"/>
        </outputCacheProfiles>
      </outputCacheSettings>
    </caching>
  </system.web>
</configuration>

The outputCacheProfiles collection configuration section is used to define cache profiles and is applied within the caching/outputCacheSettings section group. The add element is used to create new profiles, and the attributes on the element correspond to the OutputCache properties that I listed in Table 12-3. In Listing 12-10, I defined a cache profile called cp1, which reproduces the configuration of the OutputCache attribute from Listing 12-8. Listing 12-11 shows the application of the profile to the Home controller.

Listing 12-11.  Applying a Cache Profile in the HomeController.cs File

using System.Diagnostics;
using System.Threading;
using System.Web.Mvc;
using System.Web.UI;
using ContentCache.Infrastructure;
 
namespace ContentCache.Controllers {
    public class HomeController : Controller {
 
        [OutputCache(CacheProfile="cp1")]
        public ActionResult Index() {
            Thread.Sleep(1000);
            int counterValue = AppStateHelper.IncrementAndGet(
                AppStateKeys.INDEX_COUNTER);
            Debug.WriteLine(string.Format("INDEX_COUNTER: {0}", counterValue));
            return View(counterValue);
        }
    }
}

As the listing shows, the individual configuration properties are replaced with CacheProfile, which is set to the name of the profile in the Web.config file. Not only does this tidy up the code, but it allows a consistent caching policy to be applied throughout the application and makes it easy to change that policy without having to locate and modify every instance of the OutputCache attribute.

Caching Child Action Output

The OutputCache attribute can be applied to any action method, including those that are used only as child actions. This means you can specify different caching policies when using the MVC framework to compose content from child actions. To demonstrate how this works, I have added a child action method to the Home controller and applied the OutputCache attribute to it, as shown in Listing 12-12.

Listing 12-12.  Adding a Child Action to the HomeController.cs File

using System.Diagnostics;
using System.Threading;
using System.Web.Mvc;
using System.Web.UI;
using ContentCache.Infrastructure;
using System;
 
namespace ContentCache.Controllers {
    public class HomeController : Controller {
 
        [OutputCache(CacheProfile = "cp1")]
        public ActionResult Index() {
            Thread.Sleep(1000);
            int counterValue = AppStateHelper.IncrementAndGet(
                AppStateKeys.INDEX_COUNTER);
            Debug.WriteLine(string.Format("INDEX_COUNTER: {0}", counterValue));
            return View(counterValue);
        }
 
        [ChildActionOnly]
        [OutputCache(Duration=60)]
        public PartialViewResult GetTime() {
            return PartialView((object)DateTime.Now.ToShortTimeString());
        }
    }
}

You can use the Duration, VaryByCustom, and VaryByParam properties only when applying the OutputCache attribute to child actions. I have set the Duration property for the child action to be 60 seconds, which is longer than the duration for the Index action method. The effect will be that the output from the GetTime child action will be stored in the cache, even when cached output from the Index action is refreshed.

To create the partial view for the child action, I right-clicked the GetTime method in the code editor and selected Add View from the pop-up menu. I set View Name to be GetTime, set Template to Empty (without model), and checked the Create as a Partial View option. When I clicked the Add button, Visual Studio created the Views/Home/GetTime.cshtml file, which I edited as shown in Listing 12-13.

Listing 12-13.  The Contents of the GetTime.cshtml File

@model string
<div class="alert alert-info">
    The time is: @Model
</div>

Finally, I updated the Index.cshtml file to invoke the child action, as shown in Listing 12-14.

Listing 12-14.  Invoking a Child Action in the Index.cshtml File

@model int
@{ Layout = null; }
<!DOCTYPE html>
<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title>Output Caching</title>
    <link href="∼/Content/bootstrap.min.css" rel="stylesheet" />
    <link href="∼/Content/bootstrap-theme.min.css" rel="stylesheet" />
    <style>
        body { padding-top: 10px; }
    </style>
</head>
<body class="container">
    <div class="alert alert-info">
        The counter value: @Model
    </div>
    @Html.Action("GetTime")
    @Html.ActionLink("Update", "Index", null, new { @class = "btn btn-primary" })
</body>
</html>

To see the effect, start the application and periodically click the Update button. The counter value produced by the Index action method will update after 30 seconds, but the same time value from the GetTime child action will be used for a further 30 seconds.

Dynamically Setting Cache Policy

The benefit of working with the HttpCachePolicy class is that you can inspect the request from within the action method and adapt the caching policy dynamically. Listing 12-15 shows how I updated the Home controller to use the HttpCachePolicy class to change the caching policy based on the URL that was used to target the Index action method.

Listing 12-15.  Setting Cache Policy in the HomeController.cs File

using System.Diagnostics;
using System.Threading;
using System.Web.Mvc;
using System.Web.UI;
using ContentCache.Infrastructure;
using System;
using System.Web;
 
namespace ContentCache.Controllers {
    public class HomeController : Controller {
 
        public ActionResult Index() {
            if (Request.RawUrl == "/Home/Index") {
                Response.Cache.SetNoServerCaching();
                Response.Cache.SetCacheability(HttpCacheability.NoCache);
            } else {
                Response.Cache.SetExpires(DateTime.Now.AddSeconds(30));
                Response.Cache.SetCacheability(HttpCacheability.Public);
            }
            Thread.Sleep(1000);
            int counterValue = AppStateHelper.IncrementAndGet(
                AppStateKeys.INDEX_COUNTER);
            Debug.WriteLine(string.Format("INDEX_COUNTER: {0}", counterValue));
            return View(counterValue);
        }
 
        [ChildActionOnly]
        [OutputCache(Duration = 60)]
        public PartialViewResult GetTime() {
            return PartialView((object)DateTime.Now.ToShortTimeString());
        }
    }
}

I use the HttpRequest.RawUrl property to set the caching policy for the content generated by the Index action method. If the action method has been targeted by the /Home/Index URL, then I disable server caching and use the SetCacheability method to disable browser caching. The argument to the SetCacheability method is a value from the HttpCacheability enumeration, which defines the values shown in Table 12-8. If the action method has been targeted by any other URL, then I set the cache duration to 30 seconds and use the SetCacheability method to enable browser caching.

To test the effect of the changes I made to the Home controller, start the application and request the root URL for the application (/). When you click the Update button, you will see that the content is cached for 30 seconds. Navigate to the /Home/Index URL and use the F5 key to refresh the page, and you will see that the browser requests the content from the server every time—and if you look at the Visual Studio Output window, you will see that the request is passed to the Home controller for every request.

Validating Cached Content

The HttpCachePolicy.AddValidationCallback method takes a method that is called to validate whether a cached data item is valid before it is returned to the client. This allows for custom management of the content cache, beyond the duration and location-based configuration. Listing 12-16 shows how I have added a validation callback to the Home controller.

Listing 12-16.  Using a Cache Validation Callback to the HomeController.cs File

using System.Diagnostics;
using System.Threading;
using System.Web.Mvc;
using System.Web.UI;
using ContentCache.Infrastructure;
using System;
using System.Web;
 
namespace ContentCache.Controllers {
    public class HomeController : Controller {
 
        public ActionResult Index() {
 
            Response.Cache.SetExpires(DateTime.Now.AddSeconds(30));
            Response.Cache.SetCacheability(HttpCacheability.Server);
            Response.Cache.AddValidationCallback(CheckCachedItem, Request.UserAgent);
 
            Thread.Sleep(1000);
            int counterValue = AppStateHelper.IncrementAndGet(
                AppStateKeys.INDEX_COUNTER);
            Debug.WriteLine(string.Format("INDEX_COUNTER: {0}", counterValue));
            return View(counterValue);
        }
 
        [ChildActionOnly]
        [OutputCache(Duration = 60)]
        public PartialViewResult GetTime() {
            return PartialView((object)DateTime.Now.ToShortTimeString());
        }
 
        public void CheckCachedItem(HttpContext ctx, object data,
            ref HttpValidationStatus status) {
 
            status = data.ToString() == ctx.Request.UserAgent ?
                HttpValidationStatus.Valid : HttpValidationStatus.Invalid;
            Debug.WriteLine("Cache Status: " + status);
        }
    }
}

The AddValidationCallback method takes two arguments. The first is the method that will be called to validate the cached content, and the second is an object that can be used to identify the cached content in order to decide whether it is valid. In the example, I specified the CheckCachedItem method and selected the user-agent string for the object argument.

The callback method must take a specific set of arguments: an HttpContext object, the object argument from the call to the AddValidationCallback method, and an HttpValidationStatus value, which is marked with the ref keyword. The job of the callback method is to use the context to examine the request and set the value of the HttpValidationStatus argument in order to tell the ASP.NET platform whether the content is still valid. Table 12-9 shows the set of values defined by the HttpValidatonStatus enumeration. In the listing, I invalidate the cached content if the user-agent string doesn’t match the one used when the content was cached.