我原本在 Stack Overflow 上询问了这个问题，但我今天早上突然想到，这个问题可能更适合 Server Fault……
我正在使用 AJAX 向 api 发出 CORS 请求，但看到一些非常奇怪的行为：我的点击跟踪（飞行前 OPTIONS 请求）总是被 IIS 中断，并在请求交给应用程序之前返回 500。
为了进行比较，这里并排显示了失败的请求（左）和成功的请求（右），如 Firefox 的请求检查器中所示（单击可查看完整尺寸）...
不好的（左）和好的（右） CORS 请求预检选项请求的示例 http://note.io/14XuOkq
请注意，这两个请求都是 jQuery (1.8.3) 自动生成的预检请求，它们从同一页面访问同一服务器，仅相隔几秒钟。许多其他请求都运行正常，并且在 的 OPTIONS 请求失败后继续正常运行/click。但 的每个请求都/click以同样的方式失败。
/click由于缺少响应标头，预检失败ACCESS-CONTROL-ALLOW-HEADERS；但如果 IIS 允许应用程序响应请求，它将被包括在内并以状态 200 进行响应（就像右边的一样）...
我无论如何也想不通为什么 IIS 会这样做。
我应该指出，API 并不总是包含ACCESS-CONTROL-ALLOW-HEADERS响应标头。我最近才添加了它，因此我们可能正在查看某个缓存中卡住的内容的结果。话虽如此，我已经在 Firefox 和 Chrome 中尝试过，并在两者中都执行了“删除所有保存到时间开头的所有内容”，因此理论上它不应该被缓存，对吗？
/click2出于测试目的，我也尝试将 URI 更改为后修复了标头问题，因此理论上如果是其他 URI 的缓存问题，则该 URI 不应该存在缓存问题。但是，此新 URI 也存在此问题。
我是否可以在 IIS 中打开一些额外的日志来找出问题所在？我应该检查哪些设置？一些已知问题？我完全不知所措，在这里...
答案1
我看到失败的请求是一个 POST 请求。
将您的 ACCESS-CONTROL-ALLOW-METHODS 设置为包含 POST。
这应该可以解决你的问题