Angular.js: $http: unusable params passed to error handler when CORS preflight fails

[DinoChiesa]

Suppose an http POST to a different origin. This implies CORS, including a CORS preflight exchange. Now suppose the OPTIONS request returns a 500 error due to a server problem. In this case the error handler gives "" for data and 0 for status.

Seems wrong.

$http.post(myUrl, loginPayload, loginHttpConfig)
  .success(function (response) {
     ....
  })
  .error(function(data, status, headers, config) {
    // In the event of a 500 response from the implicit OPTIONS
    // request for CORS preflight, data ="", and status=0. This 
    // seems wrong.  
  });

[lucipacurar]

This is more of a browser problem. I'm having more or less the same issue. You can take a look at the XHR Object in the AngularJS code to check if actually returns a status and data. In my case the XHR Object returns status 0 which I'm assuming is happening in your case too.

[pkozlowski-opensource]

Duplicate of https://github.com/angular/angular.js/issues/2798

[kapusta]

Fwiw, I'm experiencing the status 0 problem with $http failures that are not JSONP (just a normal POST sending/receiving JSON) and the OPTIONS preflight actually succeeds. Content length of the error response is correctly set and the payload is valid JSON. The dev tools UI reports the server response as being missing ("This request has no response data available.")

Direct calls to the API end point using Postman with the same payload returns the expected error code and a correctly size payload.

CORS is involved here somewhere, but it's not limited to the OPTIONS preflight failing.

[lucipacurar]

I found the issue for a while now but I forgot post here a reply. EVERY response, even Error 500, must have the CORS headers attached. If the server doesn't attach the CORS headers to the Error 500 response then the XHR Object won't parse it, thus the XHR Object won't have any response body, status, or any other response data inside.

[kapusta]

@lucassp Thanks for the follow up, I went back and tested my APIs and the replies with 400s and 500s don't include CORS headers.

[NathanWalker]

Thank you @lucassp for your explanation above. It just saved my tail today and many hours of frustration.

[lucipacurar]

@NathanWalker I'm glad it helped :)

[aaronleesmith]

+1 This answer helped me out as well. Thank you.

[relferreira]

Thanks @lucassp.

[logusgraphics]

Thanks a lot @lucassp It was driving me crazy !

[philonor]

Thanks @lucassp, this made me searching at the right place.

Although the server was alreay sending all CORS headers, it turned out that the $http request didn't reach the server at all.
The reason was the use of a self signed certificate which made $http directly call the error handler without performing the request itself.
For me it was the combination of using $http in a PhoneGap application on iOS with a self-signed, invalid certificate.

Maybe interesting:
http://stackoverflow.com/questions/4565772/ajax-calls-to-untrusted-self-signed-https-fail-silently

[lucipacurar]

@philonor I'm glad it helped. I will start working on a PhoneGap app next week, so your issue will help me too :+1:

[keepscoding]

Thanks @lucassp for the head up.

[reecefenwick]

Hey guys.

I've run into this issue myself, @lucassp to your point before, are you saying that ALL cross origin responses in addition to preflight responses should include the CORS headers?

Is this part of the CORS specification? I'm browsing through it trying to find some explanation.

Just want to be sure as I'll need to raise a feature request with someone to solve my problem :(

[lucipacurar]

@reecefenwick Well, I had a look here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS and tried various settings based on that.