Wednesday, April 27, 2016

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.

Saturday, April 2, 2016

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 the only cookie which is required.

I am testing on a demo account which JIRA provides for trials on Atlassian Cloud. In my case for the proper authentication are also required:

  • atlassian.xsrf.token - Atlassian Cloud service's Server ID, a securely-generated random string (i.e. token) and a flag that indicates whether or not the user was logged in at the time the token was generated.
  • studio.crowd.tokenkey - authentication cookie which is used for single sign-on (SSO) between Atlassian Cloud applications. Like the JSESSIONID cookie, this cookie also contains a random string and the cookie expires at the end of every session or when the browser is closed.
More details on JIRA API cookies used by Atlassian Cloud are here: https://confluence.atlassian.com/cloud/cookies-744721661.html. I suppose in case of internal hosting of the JIRA server the cookies set may differ so a safe approach seems to be to re-send all cookies the method got during creation of the session.

Below is the example of usage of the cookie-based authentication to retrieve data from JIRA API.

    var baseUrl = //URL to your JIRA server, e.g.  https://<YOUR ACCOUNT>.atlassian.net
    var userName = ...
    var password = ...

    var dataProvider = new JiraApi();
    IDictionary<string, string> cookies;
    if (dataProvider.TryLogin(baseUrl, userName, password, out cookies))
    {
         //just for example: retrieves all issues of the specified type
         dataProvider.SearchForIssues(baseUrl, cookies, "type=Story"); 
         dataProvider.Logout(baseUrl, cookies);
    }

Actually the logout is not a required step; the cookies can be saved somewhere and used until they expired (30 days).

I used RestSharp to keep the below code simple, however the approach should also work with the plain HttpWebRequest. Also for simplicity of the example I used client.Execute instead of more convinient client.Execute<T> which allows to deserialize the response content from JSON to entities.

    
    public class JiraApi
    {
        public bool TryLogin(string baseUrl, string userName, string password, 
              out IDictionary<string, string> cookies)
        {
            var client = new RestClient(baseUrl);

            var request = new RestRequest("/rest/auth/1/session", Method.POST);
            request.RequestFormat = DataFormat.Json;
            request.AddBody(new { username = userName, password = password });

            var response = client.Execute(request);
            if (response.StatusCode == HttpStatusCode.OK)
            {
                cookies = response.Cookies.ToDictionary(x => x.Name, x => x.Value);
                return true;
            }
            else
            {
                //handle the cause of the failure based on information provided 
                //by response.StatusCode and response.Content
                //...

                cookies = null;
                return false;
            }
        }

        public void SearchForIssues(string baseUrl, IDictionary<string, string> cookies, string jql)
        {
            var client = new RestClient(baseUrl);
            var request = new RestRequest("/rest/api/2/search", Method.GET);
            request.RequestFormat = DataFormat.Json;
            request.AddBody(new { jql = jql });

            foreach (var cookie in cookies)
                request.AddCookie(cookie.Key, cookie.Value);

            var response = client.Execute(request);
            if (response.StatusCode == HttpStatusCode.OK)
            {
                var content = response.Content;

                //handle results here
                //...

            }
            else
            {
                //handle the cause of the failure based on information provided 
                //by response.StatusCode and response.Content
                //...
            }
        }

        public void Logout(string baseUrl, IDictionary<string, string> cookies)
        {
            var client = new RestClient(baseUrl);
            var request = new RestRequest("/rest/auth/1/session", Method.DELETE);
            foreach (var cookie in cookies)
                request.AddCookie(cookie.Key, cookie.Value);

            var response = client.Execute(request);
            if (response.StatusCode == HttpStatusCode.NoContent)
            {
                //handle results here
                //...

            }
            else
            {
                //handle the cause of the failure based on information provided 
                //by response.StatusCode and response.Content
                //...
            }
        }

Note that the successful deletion of the session returns NoContent status code instead of OK.

Friday, November 21, 2014

JSON Viewer. Part 2

JSON Viewer extension has now a few new features:
  • ability to print formatted data
  • ability to format input data keeping JSON markup

  • ability to compare 2 JSON data

These features are available in release 1.0.2. Source code and binaries to download are here: https://jsonviewervsextension.codeplex.com.

After installation the viewer appears in the main menu: Tools -> JSON Viewer. Applicable to VS 2012 and 2013.

Monday, November 3, 2014

JSON Viewer

Made a simple extension to Visual Studio to view JSON data in a more user-friendly format.

Source code and binaries to download are here: https://jsonviewervsextension.codeplex.com. After installation the viewer is available in the main menu: Tools -> JSON Viewer.

Applicable to VS 2012 and 2013. Please note that custom VS extensions cannot be installed into Express editions of Visual Studio due to a Microsoft policy.

Sunday, October 19, 2014

Not So Primitive Types

A few nuances about the primitive types in .Net which are not so obvious:
  • If you add two shorts you will get int. The same with bytes. Arithmetic operators for these types are not implemented in .Net therefore the values are implicitly converted to int before calculation.
        short x = 2, y = 2;
        var z = x + y;
        Console.WriteLine(z.GetType()); //output: System.Int32 
    
  • Chuck Norris is not the only person who can divide by zero. Every .Net developer can do this. Just use floating point numbers.
        var z = 1.0 / 0;
        Console.WriteLine(z); //output: Infinity