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...

Community
  • 1
Adam Tuttle
  • 213
  • 3
  • 14

1 Answers1

0

I see the failing request is a POST request.

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

That should fix your problem

Jacques Snyman
  • 121
  • 2
  • 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. – Adam Tuttle Jun 14 '13 at 13:13