Sponsored

Thursday, November 7, 2013

Setting Cache Control HTTP Headers in Web API Controller Method

Controlling caching behaviour of an HTTP response is an important task that cannot be ignored as it will have a big impact on a web application load and performance. In ASP.NET Web Forms and MVC applications it usually is done by using special directives or attributes that take care of adding corresponding headers to the response. ASP.NET Web API framework unfortunately does not come with an out of the box support for this functionality so concious developers need to deal with that themselves. Luckily it is not a difficult task to do as the Web API framework has a number of support objects that simplify the job.

Basically in order to control caching behaviour we need to make sure that the output response will have what is called "Cache control header" with proper values that determine caching behaviour. Example below demonstrates how to make a response publicly cacheable for a period of time:
   var response = new HttpResponseMessage();
   response.Headers.CacheControl = new CacheControlHeaderValue
          {Public = true, MaxAge = TimeSpan.FromSeconds(maxAge)};

To simplify the usage further we can even create a static extension method that can be easily applied in a controller method:
// somewhere in a static class
public static HttpResponseMessage PublicCache(this HttpResponseMessage response, int maxAge)
{
   response.Headers.CacheControl = new CacheControlHeaderValue
          {Public = true, MaxAge = TimeSpan.FromSeconds(maxAge)};
   return response;
}
...
// inside an ApiController class
public HttpResponseMessage MyApiMethod(long id)
{
   var response = new HttpResponseMessage();
   ..............
   return response.PublicCache(24 * 7 * 60);
}

Wednesday, November 6, 2013

ASP.NET and SSL Offloading

SSL offloading is quite a popular method of improving a web server performance by delegating a CPU-intensive SSL processing operations to an external device such as a load balancer. Because having a load balancer only makes sense when there are multiple web servers working in a farm it looks like an attractive solution for maximizing usage of a load balancer and at the same time improving performance of web servers by freeing them from doing an "unnecessary" SSL processing. What also makes SSL offloading a high profile feature is load balancing appliance vendors marketing SSL offloading as one of the selling points of their products.

With all above said being correct it is not always recommended to rush for turning SSL offloading on. One very specific use case is an ASP.NET application using  Web Forms authentication configured to serve protected content over secure connection only. What that means is when a request for a protected page sent over unsecured HTTP the application will redirect it to a secured version of the Url. But because the SSL request never reaches a web server (since it's being intercepted by a load balancer and converted into HTTP request) the application logic will be stuck in an infinite redirect loop. To resolve the problem there are only two options: allow protected content over an unsecured connection or disable SSL offloading. If there is more of an application logic that requires secured connection between client an a server it makes more sense to not use SSL offloading at all.

There are however scenarios when SSL offloading is very helpful. Examples include but no limited to many kinds of data processing service-like web applications that are not intended to return human-readable HTML output, TCP/IP based data processing applications that do not use HTTP at all and so forth. Most likely such applications will not base their logic on a condition of a secure connection with a client.

What are PROs and CONs of using SSL offloading? Obviously one positive point is web servers performance improvement by removing SSL processing from their plates. How important that could be? Most likely that depends on traffic. For high traffic high profile publicly accessible web servers that could be very important but in such cases all the efforts must be made to not couple application logic with a type of client-server connection. From another hand modern server CPUs implement specialized command sets that make SSL processing much less intensive and not so terrifying a task for web servers so it could be more convenient to allow secure traffic directly to web servers.

Another consideration is how secure traffic passing between an SSL offloading load balancer and a web server is. Obviously both devices are supposed to be behind a firewall but it needs to be take care of because traffic may contain sensitive information and in such a case load balancer could become a point of attack.

One more concern is IT maintenance. Secured infrastructure requires setting up and maintaining SSL certificates and other components. If there are a lot of web servers in a farm it could make sense to minimize maintenance by centralizing all SSL configurations on SSL offloading devices.

In conclusion, understanding specifics of a particular implementation is crucial for making a correct decision about using SSL offloading technique.