Skip to main content

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:


Someone likes this approach:

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

The most careful developers use both:


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.
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";
//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.


Popular posts from this blog

How to merge cells with equal values in the GridView

My solution is not the first; however, I think, it is rather universal and very short - less than 20 lines of the code.

The algorithm is simple: to bypass all the rows, starting from the second at the bottom, to the top. If a cell value is the same as a value in the previous (lower) row, then increase RowSpan and make the lower cell invisible, and so forth.

The code that merges the cells is very short:
public class GridDecorator { public static void MergeRows(GridView gridView) { for (int rowIndex = gridView.Rows.Count - 2; rowIndex >= 0; rowIndex--) { GridViewRow row = gridView.Rows[rowIndex]; GridViewRow previousRow = gridView.Rows[rowIndex + 1]; for (int i = 0; i < row.Cells.Count; i++) { if (row.Cells[i].Text == previousRow.Cells[i].Text) { row.Cells[i].RowSpan = previousRow.Cells[i].RowSpan < 2 ? 2 : prev…

Merging columns in GridView/DataGrid header

As necessity to show header columns in a few rows occurs fairly often it would be good to have such functionality in the GridView/DataGrid control as an in-built feature. But meanwhile everyone solves this problem in his own way.

The described below variant of the merging implementation is based on irwansyah's idea to use the SetRenderMethodDelegate method for custom rendering of grid columns header. I guess this approach can be simplified in order to get more compact and handy code for reuse.
The code overview
As it may be required to merge a few groups of columns - for example, 1,2 and 4,5,6 - we need a class to store common information about all united columns.
private class MergedColumnsInfo
// indexes of merged columns
public List<int> MergedColumns = new List<int>();
// key-value pairs: key = the first column index, value = number of the merged columns
public Hashtable StartColumns = new Hashtable();
// key-value pairs: key = the first column in…

JIRA REST API: Cookie-based Authentication

Three authentication methods are proposed by the JIRA REST API documentation: Basic Authentication is a simple but not very safe approach. Credentials are sent in the header on every request and encoding to Base64 is not a proper protection in this case; HTTPS connection is required. OAuth authentication - looks a bit complex and requires additional configuration at the JIRA server that is not always possible. Cookie-based Authentication - this approach seems to be the most convinient one: credentials are checked once, then the authentication cookie only is sent on subsequent requests. However, trying to use the cookie-based authentication I encountered an issue. The approach described in the documentation worked partially: I was able to create a new session and get the response containing the session cookie but all subsequent requests using this session cookie were rejected as unauthorized. Spending some time investigating this I found the cause of the issue: JSESSIONID is not th…