Caching HTTP Handlers

There comes a time in an ASP.Net developer's life when he must write own HTTP handler. Quite often the handler has to return a static or a rarely changable content and the developer should implement caching of it.

Step 1. Specify how long data should retain cached.

Someone does it this way:

  context.Response.Cache.SetExpires(DateTime.Now.AddDay(1));

Someone likes this approach:

  context.Response.Cache.SetMaxAge(86400); //1 day in seconds

The most careful developers use both:

  context.Response.Cache.SetExpires(DateTime.Now.AddDay(1));
  context.Response.Cache.SetMaxAge(86400);

All the above are correct in their own way. The first example sets an absolute expiration date. In the list of headers it looks like this:

Expires: Mon, 25 Jul 2016 19:50:09 GMT

This header was introduced in the HTTP/1.0 specification but it is supported by HTTP/1.1 too. A small pitfall related to this header is that the expiration date and time are set explicitly and it may cause issues if time at an application server and proxy servers differ.

In order to fix the above issue a new header was introduced in HTTP/1.1: max-age. It specifies expiration time relatively to response time, i.e. an interval, in seconds, after elapsing it cached data are considered stale (expired).

Cache-Control: max-age=86400

In case both headers are set max-age has priority even if an Expires value is more restrictive.

At this stage many developers consider their work done and switch to other tasks. However...

Step 2. Define where to store cached content.

Let's run a HTTP trafic analyser, e.g. FireBug and look how our cached resource is loaded. Quite often we can notice that the resource is loaded again and again on each refresh with the 200(OK) status but without the (from cache) remark. Look at this header:

Cache-Control: private, max-age=86400

Private means that data can be cached by browsers only and cannot be cached at servers. Assuming that the browser cache is limited (e.g. the default size of the cache of Firefox is 50 MB) a browser you use may decide that letting a web site to occupy too much space is not the best idea and purge cached data. So if cached data are not "user sensitive" it makes sense to store them on servers.

context.Response.Cache.SetCacheability(HttpCacheability.Public);

More sophisticated options are described here: HttpCacheability Enumeration

At this stage even more developers conclude that their work done and switch to other tasks. However...

Step 3. Handle renewval of cached data.

Let's consider the following cases:

• Proxy servers are overloaded and remove entries from the cache from time to time;
• Cached entries are expired but still are not changed.

As a result the cached entries will be retrieved from the application server; this will increase traffic and reduce perfomance.

A proper approach is to avoid loading all data but just to return a response with 304 (Not changed) status. In order to do this set the Last Modified header:

context.Response.Cache.SetLastModified(new DateTime(2016, 4, 1));

which produces the output like this:

Last Modified: Fri Apr 1 2016 00:00:00 GMT

A server discovering that a cache entry is stale (expired) requests for a fresh copy of the entry and sends the If-Modified-Since header with the current date/time. We can handle this case and return a light-weight 304 response instead of sending the whole content.

var ifModifiedSinceHeader = context.Request.Headers["If-Modified-Since"];
if (!string.IsNullOrEmpty(ifModifiedSinceHeader))
{
    var ifModifiedSinceDate = DateTime.Parse(ifModifiedSinceHeader);
 
    if (/*cached data are not modified since this date*/)
    {
        context.Response.StatusCode = 304;
        context.Response.StatusDescription = "Not Modified";
        return;
    }
}
 
//otherwise return the normal response containing data and 
//do not forget about setting the Last Modified header...

Actually the above approach is basic one; it does not describe a lot of useful headers which can be used for tune adjustments of the caching process, e.g.: ETag, must-revalidate, etc.