9

Edit: I just realized this is a duplicate of Recommended solution for AJAX, CORS, Chrome & HTTP error codes (401,403,404,500), and he tried the idea I propose at the end. But I can't tell if he succeeded (dud user?), and no one else has posted a solution or even a comment, so I think it's worth fishing for new answers.

Problem:

  • I send a properly-executed (edit: IMproperly-executed. End of story...) CORS request.
  • The server receives the request and attempts to process it.
  • The server returns an error response, for example a 422 Unprocessable Entity, along with JSON information about the errors. The idea is that my app could receive this error information and handle it appropriately in the UI.
  • The browser blocks my error handler from getting the response content, or even getting the status code.

Showing that the browser received the 401 status code but treated it as a CORS security error:

Status Code 401

The response object, showing that my code cannot access the response data (data: "", status: 0):

Obscured Response Object

How have other people handled this limitation? My best guess right now is to hijack an HTTP "success" code (2XX) as an error code, and then include the error information in the response. This prevents me from using the ajax error handlers in a normal way, but I'm handling this as a global ajax filter anyway, so this filter would capture the deviant success code and trigger the error handlers instead.

Community
  • 1
  • 1
colllin
  • 9,024
  • 9
  • 47
  • 62

3 Answers3

5

The console message indicates that the server isn't sending the required Access-Control-Allow-Origin header when it sends the 401 response code.

You won't be able to use the CORS error handler to inject content into the DOM unless you fix that.

The server is likely sending the header correctly on responses with a 200 response code. It needs to do it for other response codes, though, if you wish to use data from those response codes.

Fix that on the server end before making design compromises on the client side. That may solve your problem straight away.

Trott
  • 59,820
  • 22
  • 153
  • 197
  • I said it's a properly-executed CORS request. When the server responds with a success code, the browser processes it correctly. – colllin Nov 02 '14 at 01:26
  • 2
    The server is sending the necessary headers on success. It needs to send them on failure too. – Trott Nov 02 '14 at 01:27
  • 5
    In other words, you need to send the CORS header on response codes other than 200 if you wish to use the JSON data from response codes other than 200. – Trott Nov 02 '14 at 01:35
-1

It seems it's an opaque response where you can't obtain the headers or the response. And everything is set to null or empty.

https://developer.mozilla.org/en-US/docs/Web/API/Response/type

Or maybe in the server you should add:

Access-Control-Allow-Origin: *
Yves M.
  • 28,433
  • 22
  • 100
  • 135
Andrew Taylor
  • 1
  • 1
-1

Very late answer but in case someone wants to check whether an error occurred while sending an XMLHttpRequest and then take appropriate actions (on the CLIENT side), then this is a quick workaround: 

try{
    request.send();
}catch(err){
    if(e.toString().startsWith("NetworkError")){
        //pasre the string to check error code
        //and take appropriate actions
    }
}

This is needed because the onreadystatechange function doesn't get executed when a NetworkError occurs and, in fact, the whole script is terminated.

progyammer
  • 1,488
  • 3
  • 15
  • 29