0

I originally asked this on Stack Overflow, but it occurred to me this morning that it may be a question better suited for Server Fault...


I'm using AJAX to make CORS requests to an api, but seeing some really odd behavior: my click-tracking (pre-flight OPTIONS request) is always interrupted by IIS and returns 500 before the request is handed off to the application.

For comparison purposes, here's a side-by-side of a failing request (left) and a successful request (right) as seen in Firefox's request inspector (click through for full-size)...

example of bad (left) and good (right) CORS request pre-flight options requests http://note.io/14XuOkq

Note that both of these requests are automatically generated pre-flight requests created by jQuery (1.8.3), hitting the same server, from the same page, just a few seconds apart. A plethora of other requests work fine, and continue to work fine after the failed OPTIONS request for /click. But every request for /click fails in this same way.

The pre-flight for /click fails because of the missing ACCESS-CONTROL-ALLOW-HEADERS response header; but if IIS allowed the application to respond to the request, it would be included and would respond with status 200 (just like the one on the right)...

I can't for the life of me figure out why IIS would be doing this.

I should note that the API has not always included the ACCESS-CONTROL-ALLOW-HEADERS response header. I only recently added that in, so it's possible that we're looking at the result of something stuck in a cache somewhere. That said, I've tried in both Firefox and Chrome, and done a "delete all saved everything to the beginning of time" in both, so in theory it shouldn't be cached, right?

I've also tried changing the URI to /click2 for testing purposes, after fixing the headers issue, so in theory it shouldn't be a caching issue for that URI, if it is for the other. However, the problem persists with this new URI, too.

Is there some extra logging I can turn on in IIS to find out what the problem is? Settings I should check? Some known issue? I'm at a complete loss, here...

1 Answer 1

0

I see the failing request is a POST request.

Set your ACCESS-CONTROL-ALLOW-METHODS to include POST.

That should fix your problem

1
  • I can see why you would be confused, however the two visible requests are to different resources. The failing one goes to /click which only allows POST, and the working one goes to /taskbox which only allows GET. (I can't include a screenshot of a working request to /click because it never works.) However, the issue here is that IIS is returning 500 before letting the application handle the request. If it did involve the application, then an appropriate ACCESS-CONTROL-ALLOW-METHODS header would be returned. Jun 14, 2013 at 13:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .