IE vs. Chrome for Debugging Ajax Web Service Calls

I was recently attempting to get Cross Origin Resources Sharing (CORS) working with some of our web services so we can more easily achieve cross-domain calls in our product lines.  Having never done any work with CORS before, I found a tutorial and started configuring the project for CORS support.  Since I wasn’t really concerned with security for my first attempt at this I figured I would go with the most lax option available, so I decorated my Web API Controller class with the following attribute:

[EnableCors("*", "*", "*")]

I figured the best way to avoid trouble was to avoid securing anything at all, at least for the time being.  I then headed back over to my browser to experience the glory and simplicity of cross-domain web services calls with CORS.  My web service call was setup to display a “success” or “failed” message depending on the outcome of the call

$.ajax({
  method: "GET",
  url: "https://server/webservice",
  xhrFields: { withCredentials: true }
})
.done(function()
  {
    alert('Worked');
  })
.fail(function (jqXHR, textStatus, errorThrown)
  {
    alert('Failed');
  });

So I hit F5 and was greeted with a big “Failed” message.  So it was time to debug.  I was in IE so I attached to the debugger so I could look at the jqXHR and textStatus values on the .fail method to give me some indication of the error.  And this is what I got back from IE:

“Error”

Thanks IE, super helpful.  The network trace from IE was showing a response of 200 from the web service with no message body, which seemed odd to me.  So then I decided I would give it a shot in Chrome in the hopes that it would give me something to work with.  I still got an error, but the message was a bit more detailed:

 A wildcard ‘*’ cannot be used in the ‘Access-Control-Allow-Origin’ header when the credentials flag is true. Origin ‘https://somehostname/’ is therefore not allowed access. The credentials mode of an XMLHttpRequest is controlled by the withCredentials attribute.

As you can imagine, that was far more useful.  So my use of the wildcard to avoid any issues is what was causing my issues.  So I updated the EnableCors attribute accordingly:

[EnableCors(https://somehostname/, "*", "*")]

So I hit F5 and was greeted with a big “Failed” message.  Not suprisingly, the error message from IE was the same:

“Error”

The error message from Chrome was, once again, much more helpful:

Credentials flag is ‘true’, but the ‘Access-Control-Allow-Credentials’ header is ”. It must be ‘true’ to allow credentials. Origin ‘https://somehostname/’ is therefore not allowed access.

And this led me to the final solution, updating the EnableCors attribute once again:

[EnableCors(https://somehostname/, "*", "*",
    SupportsCredentials = true)]

Finally, I got the “Worked” message I was looking for when calling the web service.  So the moral of the story is use Chrome if you are debugging network issues because the error messages are much more informative.