dalelane's soup

If you’re one of that exceedingly rare breed who regularly check or subscribe to my blog, you probably want to give this post a miss. This one is more for people who find me through Google. A specific solution to a specific, geeky, problem.

Background

First a little scene setting…

Server side

I have a REST API that uses ETags for, amongst other things, concurrency control. That is, the version of an entity is (opaquely) identified by an ETag. You need to specify that ETag when you try and make any changes to that entity. If someone else changes the entity before you do, your ETag won’t match, so your update will fail, and you won’t unintentionally roll-back their change.

The REST API returns no content (HTTP 204) in response to a successful PUT request to edit an entity, and includes the new ETag representing the version of the updated entity.

Client side

I have a Dojo web tool that uses xhr.put to submit edits to the REST API. In order to make further subsequent edits to an entity without reloading the page, it stores the ETag that it gets back in the response header after every PUT.

The problem

In short, Internet Explorer.

In more detail, it seems that there is a bug in Internet Explorer when it gets a 204 no-content response to an xhr request from Javascript.

IE does drop whatever it uses to store the response content. Unhelpfully, it also drops all of the response headers.

This means my client side Javascript doesn’t get the updated ETag returned by the server.

It means my Javascript can make one update to the entity. After this, it doesn’t have the correct ETag required to make any subsequent updates.

This bug seems to be present on all versions of IE that I tried, including the latest-and-greatest.

A workaround

One way of handling this without needing to modify the REST API is to extend the behaviour of xhr.put so that, when running on Internet Explorer only, it follows up a successful PUT with a HEAD call to the same entity. This is just enough to get the updated response headers – to fetch the updated ETag that IE dropped from the PUT.

By daisy-chaining the two requests, this is invisible to code that calls xhr.put.

This is implemented as a module myproject/xhr to use in place of dojo/_base/xhr. It behaves in the same way as dojo/_base/xhr, with the exception of this additional workaround.

define(["dojo/_base/declare", "dojo/_base/xhr", "dojo/_base/sniff", "dojo/_base/lang"],
    function (declare, xhr, sniff, lang) {

    function myXhr() {
        //
        // if we are using a JSON with ETags handler, then we are interested
        //  in the the entity tag contained in the response header of the POST/PUT
        //  requests
        //
        // however, on Internet Explorer, this response header is missing,
        //  because of the bug described at http://www.enhanceie.com/ie/bugs.asp
        //  (IE0013: IE XMLHTTP implementation turns 204 response code into bogus 1223 status code)
        //  so we have to perform an additional GET to fetch the updated
        //  entity tag.
        //
        // this bug is present on IE7-IE9 so we do this for any version of IE
        //

        this.put = function (request) {
           if (sniff("ie")) {
               return xhr.put.apply(this, arguments).then(lang.hitch(this, function(response){
                   delete request.headers['If-Match'];
                   return xhr("HEAD", request);
               }));
           }
           else {
               return xhr.put.apply(this, arguments);
           }
        };
    };

    myXhr.prototype = xhr;

    return new myXhr();
});

Postscript

Oh IE, for crying out loud. How much more could we get done if we didn’t have to spend so much time working around your little quirks?!