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... :-)
On Friday, September 26, 2014 2:17:18 PM UTC-4, Eric Eslinger wrote:
>
> correction, I do
>
> $http.get('http://example.com/bindata.jpg', {responseType: 'arraybuffer'})
>
> dunno if the camelcase is significant, probably is.
>
> e
>
> On Fri, Sep 26, 2014 at 11:15 AM, Eric Eslinger <[email protected]
> <javascript:>> wrote:
>
>> I do this: $http.get('http://example.com/bindata.jpg', {responseType:
>> 'arrayBuffer'})
>>
>> all the time and it works.
>>
>> On Fri, Sep 26, 2014 at 10:35 AM, highdown <[email protected]
>> <javascript:>> wrote:
>>
>>> I posted this issue on Stack Overflow at AngularJS GET byte[] error
>>> when downloading binary data using ASP.NET Web API
>>> <http://stackoverflow.com/questions/26059955/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...
>>>
>>> --
>>> 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 [email protected] <javascript:>.
>>> To post to this group, send email to [email protected]
>>> <javascript:>.
>>> Visit this group at http://groups.google.com/group/angular.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.