Google Chrome AJAX call for BLOB is several KB short in size

Question

Background and snippet of code

I've been writing this code for a year and a half and I had no issues until the most recent update to chrome (Version 33.0.1750.117 m on Windows 7). I don't know how to set this up for others to easily replicate. I simple want to know, why I'm getting incorrectly returned blob (incorrect sizes that is) without any errors being thrown? (Am I missing something???)

I'm making AJAX calls (code to follow) which are handled in a Java Servlet, a call is made to an Oracle Database and BLOB objects are streamed from the database.

The issue here is that the BLOB returned is a different in size each request, and only occasionally is the size of the blob the same size in bytes as what is stored in the database(411238 bytes)... This only occurs in the recent version of Chrome.

The AJAX syntax - code in question

var xhr2 = new XMLHttpRequest();
xhr2.responseType = 'blob';
xhr2.onload = function(e2){
    console.log(xhr2.response);
    /**Other irrelevant code to the problem - response handling code**/
}
xhr2.open('GET', "/data.get?cmd=getcol&col="+colID+"&sid="+sid, true);
xhr2.send();

Everything below this point is results from making the above AJAX call or attempts at resolving the issue

---

The following is a copy-paste the console logs of the xhr2.response from the AJAX request.

Blob {type: "text/xml", size: 403610, slice: function}
Blob {type: "text/xml", size: 404058, slice: function}
Blob {type: "text/xml", size: 408378, slice: function}
Blob {type: "text/xml", size: 410675, slice: function}
Blob {type: "text/xml", size: 403610, slice: function}

And finally it returned the correct size:

Blob {type: "text/xml", size: 411238, slice: function}

Here are the results when I made the EXACT same javascript AJAX request on my non-updated chrome on a laptop 10 out of 10 attempts ( Chrome Version 32.0.1700.107 m )

Blob {type: "text/xml", size: 411238, slice: function}

Also, we exhausted the possibility of the issue being either the servlet or oracle's problem because making the same requests from JAVA instead of a web browser returned the correct sized object.

It's almost as if a stream was closed before it's contents were flushed... but it is doing the job correctly on the server side(flushing the stream that is).

The XHR Object from the console

---

Update 1 - 3-1-2014

Header's view from dev console on an AJAX request that's returned blob size was incorrect.

---

Update 1 - 3-3-2014

On the server I added the content-length to the HTTP response, which keeps the transfer-encoding from being set see this answer for reasoning. Unfortunately this didn't keep the AJAX call from sometimes returning the wrong sized blob.

Also, I attempted to change the accept-encoding via xhr2.setRequestHeader("Accept-Encoding","identity"); in the javascript. The browser prevented me from doing so for security reasons See here for more info

Answer 1

It appears to be a Chrome bug. I hit the same issue on Chrome 33.0.1750.152 on Mac OS X. I could not reproduce the issue on Firefox and Safari, and after two days of suspecting the server side for dropping the last write before closing the socket, inspecting packet traces, etc., I tried converting the 'short' blob to text using FileReader. Funnily enough, all the data is there, and the length of the string is correct (longer than blob.size)

But if you use this "bad" blob in another blob constructor, like var b = new Blob([b1, badblob]), then b is going to have a short size.

As a workaround, you could use a FileReader and convert it to a binary string. If you're sure you're always going to be getting text/html, then readAsText() is more convenient.

    var fr = new FileReader();
    fr.onload = function(e) {
        var res = e.target.result,
            len = res.length;
        // len will be the correct length (len > blob.size).
        return cb(null, e.target.result);
    };
    // blob.size will be a short size
    fr.readAsBinaryString(blob); // Use fr.readAsText() if your blob is text

UPDATE: I've (temporarily) hosted a simple repro case at http://pigshell.com/dev/chromebug.html - the problem appears aggravated if the server does not keepalive the connection, but forces the client to reopen new ones for every request.

The good news is that after updating Chrome to the latest version: 34.0.1847.116, I could not repro the issue any more.