AngularJS GET Corrupts Returned Byte[] Data... XMLHttpRequest GET Works

[highdown]

I posted this issue on Stack Overflow at  AngularJS GET byte[] error when downloading binary data using ASP.NET Web API.

I created a simple test case to reproduce this issue. The GET method on the server simply generates a byte[] that has 256 elements with values 0-255.

When I wrote an alternate implementation in my SPA using vanilla XMLHttpRequest the data is read properly and the returned data is in the correct array format.

There are 3 issues that I have documented at the link above.

1. The first issue with the Angular code is that it interprets the data as a string, NOT a byte array, while the XMLHttpRequest code interprets that code correctly as a byte array.
2. The second issue is that the AngularJS code corrupts all values greater than 127 (i.e., 128-255). See link above.
3. The third issue is that data is lost. The reconstructed data in the AngularJS code had only 217 bytes instead of 256 bytes.

It seems logical that there are two possibilities: 1) My AngularJS code has a error or missing information (likely, and I am all ears), or 2) AngularJS has a bug that is causing this.

The code that I used is documented at the link provided above, along with detailed tests/results.

I found something when I stepped through the Angular $http code that didn't seem right to me. In these code blocks, the responseType was set to "arrayBuffer", which is correct.

    function $http(requestConfig) {

      var config = {

        method: 'get',

        transformRequest: defaults.transformRequest,

        transformResponse: defaults.transformResponse

      };

      var headers = mergeHeaders(requestConfig);

************************************************************************

  // TODO(vojta): fix the signature

  return function(method, url, post, callback, headers, timeout, withCredentials, responseType) {

    var status;

************************************************************************

      if (responseType) {

        try {

          xhr.responseType = responseType;

        } catch (e) {

          // WebKit added support for the json responseType value on 09/03/2013

          // https://bugs.webkit.org/show_bug.cgi?id=73648. Versions of Safari prior to 7 are

************************************************************************

However, in the following code block, the responseType value seems to have been cleared.

            // responseText is the old-school way of retrieving response (supported by IE8 & 9)

            // response/responseType properties were introduced in XHR Level2 spec (supported by IE10)

            response = ('response' in xhr) ? xhr.response : xhr.responseText;

From what I have read, the responseType should be set to “arrayBuffer” at this point in the code. Other than this data possibly being incorrect at the point in the code, I do not have a clue as to what might be causing this issue.

I have been working on an Angular fix for over a week, but have only found a solution that is outside the Angular Framework.

Thanks much for your consideration...

[Eric Eslinger]

I do this: $http.get('http://example.com/bindata.jpg', {responseType: 'arrayBuffer'})

all the time and it works.

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

[Eric Eslinger]

correction, I do

$http.get('http://example.com/bindata.jpg', {responseType: 'arraybuffer'})

dunno if the camelcase is significant, probably is.

e

[highdown]

The case definitely matters. Used lowercase 'b' and it works like a charm. I will give you credit on Stack Overflow. If you want points, please answer officially and I will accept your answer.

Thanks... :-)

[Eric Eslinger]

cool, thanks. I could always use the SO cred.

e // pfooti