Response code with IE10 and CORS

[Traxmaxx]

response.status is always 0 instead of 401 when the Server returns Authorization Required and you're doing CORS in IE10 on Windows 7.

My first solution

if (response.status === 401 || response.status === 0) {
  //Handle error here
}

But this lead to a new bug:

Everytime you hit refresh in your browser and some AJAX calls are not finished, the error callback gets triggered with a response.status of 0.

2nd solution

var isPageBeingRefreshed = false;

window.onbeforeunload = function () {
  'use strict';
  isPageBeingRefreshed = true;
};

var myApp = angular.module('myApp', ['http-auth-interceptor']);

and check it against response.status in the error callback

if (response.status === 401 || (response.status === 0 && !isPageBeingRefreshed)) {
  //Handle error here
}

My first try was to check xhr.readyState. This failed because it's always 4, also if you're hitting reload and the call was not finished at all.

The error were reported around Dec 12. I was not able to find any other updates. Maybe theres a better solution or hopefully a bugfix soon.

I'm also curious if someone can verify this bug in IE10 on Windows 8.

[DrDelete]

Same bug encountered on Win8 with IE10/CORS.

[Traxmaxx]

Thanks for the info. Any plans for fixing this on master or is this use-case too rare? The solution above is still working but it could be prettier though.

[stereokai]

@witoldsz, as the maintainer of this module, what is your view on this issue? Thank you.

[witoldsz]

I think that fixing or walking over the bugs of the thing called IE is out of the scope of this project. I am pretty sure someone can provide a fix for broken IE XHR requests for AngularJS (or maybe a lever below AngularJS), maybe as a $http interceptor, so once the response hits this one, the status code will be correct already.

[stereokai]

Are $http interceptors different than $httpProvider interceptors?

[witoldsz]

@stereokai $http is a service created (provided) by $httpProvider. We register "HTTP interceptors" when configuring the $httpProvider, so $http service has them once it is created.

[stereokai]

How can you make sure the interceptor responsible for taking care of the IE bug takes place before any other interceptor? Declare (push) it first?

[witoldsz]

Well, looking at the API, I guess you have to push it at the beginning of the queue and make sure there are no other modules pushing anything before it. I can't recall any other priority mechanism for http interceptors.

[stereokai]

Sweet, thank you.

[scott-cornwell]

Looks like this has been changed in 1.3, I was having problems because Angular was turning status of 0 into a 404 before the interceptors fired. Thanks!

[kelu95]

Well, with chrome and latest angular (1.3.0-beta.17), angular always return status 0 on OPTIONS request error. Is it possible to fix that ? Thanks

[witoldsz]

What am I supposed to do? Fix Angular, Chrome, both?

[kelu95]

maybe you can try :) But is it possible to test response.status === 0 as on 1st comment ?

[witoldsz]

No, that is not possible, I am sorry. But you can do it in your own $http interceptor and insert it at the beginning, so this module will see whatever you tweak over there.

[stereokai]

What am I supposed to do? Fix Angular, Chrome, both?

@witoldsz If there was a bash.org for Github Comments, this comment would be ranked #1.

[bobbly13]

Not sure if people found a resolution to this, but I found that status 0 was only returned if the Pre-Flight OPTIONS request returned a non 200 code.

It seems that the Angular $resource module has logic to translate these status codes to a 0.

If I make OPTIONS requests non authorised on the server side then when the subsequent request (GET,POST, etc) is made then the status is correctly returned as 401 formunathorised

Express example:

app.use(jwt({ secret: secret}).unless({ method: 'OPTIONS', path: ['/token']}));