IIS劫持CORS preflight OPTIONS请求 [英] IIS hijacks CORS Preflight OPTIONS request

问题描述

我想提出一个CORS POST请求，并设置Content-Type头，以JSON。这会触发preflight OPTIONS请求解雇（这是好的和预期）

I am making a CORS POST request and setting the Content-Type header to json. This triggers a Preflight OPTIONS request to fire (this is good and expected)

这OPTIONS请求响应与200 OK，但这不是从我的WebAPI的应用程序来。

This OPTIONS request is responded to with a 200 OK but this isn't coming from my WebAPI application.

我有一个适当的定制消息处理程序，它永远不会得到我们打这样的要求是越来越由IIS击中ASP.NET似乎之前作出回应。

I have a custom Message Handler in place and it never get's hit so the request is getting responded to by IIS prior to hitting ASP.NET it seems.

我发现关于这个问题的几个职位，他们说以下

I have found several posts on the subject and they say the following

1. 确认WebDAV是卸载/删除/禁用 - 完成

确保OPTIONSVerbHandler被删除/改为ASPNET_ISAPI.DLL使用 - 都试过

Make sure the OPTIONSVerbHandler is removed / changed to use aspnet_isapi.dll - TRIED BOTH

确保extensionlessURLHandler包括OPTIONS动词 - 完成

Make sure the extensionlessURLHandler includes the OPTIONS verb - DONE

不过，我的选择是请求仍得到劫持。我的意思是，IIS与200 OK响应，但不包括在响应的访问控制允许来源头。它不包括这个头，因为它永远不会让我的WebAPI CORS code，将设置此头。

However, my options request is still getting hijacked. By that I mean, IIS responds with at 200 OK but isn't including an Access-Control-Allow-Origin header in the response. It isn't including this header because it is never getting to my WebAPI CORS code that would set this header.

最好的两个职位我能找到那声音就像我的问题是

The two best posts I could find that sound like my issue are

这里：<一href=\"http://stackoverflow.com/questions/14897247/jquery-stuck-at-cors-$p$pflight-and-iis-ghost-response\">JQuery停留在CORS preflight和IIS鬼响应

在这里：<一href=\"http://brockallen.com/2012/10/18/cors-iis-and-webdav/\">http://brockallen.com/2012/10/18/cors-iis-and-webdav/

我试图打开失败请求在IIS跟踪（小佛），并设置其跟踪所有200状态codeS。我从来没有看到的选项要求被记录...不知道这是否意味着小佛不跟踪OPTIONS请求，或者如果我需要改变某些事情在小佛的设置，使其跟踪OPTIONS请求，或者如果这是一个线索我的问题是什么？

I have tried turning on Failed Request tracing (FERB) in IIS and set it to trace all 200 status codes. I don't ever see the options request being logged... Not sure if this means FERB doesn't track OPTIONS requests or if I need to change something in the FERB settings to make it track OPTIONS requests, Or if this is a clue to what my problem is?

这是ASP.NET的WebAPI 2.0在IIS 7.5上运行（在IIS 8，用相同的结果IISEx preSS还测试）
什么都无所谓浏览器（Chrome，FF和IE都无法以同样的方式）

This is ASP.NET WebAPI 2.0 running on IIS 7.5 (Also tested on IIS 8 and IISExpress with same results) Doesn't matter what browser (Chrome, FF, and IE all fail the same way)

我已经试过各种我能找到关于这个问题，仍然无法解决我的问题。

I have tried everything I can find on the subject and still can't fix my problem.

帮我计算器，你是我唯一的希望。

Help me StackOverflow, you're my only hope.

推荐答案

一对夫妇的事情，你可以尝试在这里，所有的web.config相关的，首先修改的模块元素，包括属性 runAllManagedModulesForAllRequests =真正的，如下：

A couple of things you can try here, all web.config related, firstly modify your modules element to include the attribute runAllManagedModulesForAllRequests="true", as below:

<modules runAllManagedModulesForAllRequests="true">
    <remove name="WebDavModule" />
</modules>

然后设置你的处理程序为如下：

Then set your handlers to the below:

<handlers>
   <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
   <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
   <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
   <remove name="WebDav" />
   <remove name="OPTIONSVerbHandler" />
   <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
   <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
   <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>

这应该做的伎俩，但如果没有，作为最后的手段可以强制IIS以输出正确的标题与下面的：

This should do the trick, but if it doesn't, as a last resort you can force IIS to output the correct headers with the below:

  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Access-Control-Allow-Origin" value="*" />
        <add name="Access-Control-Allow-Methods" value="GET,PUT,POST,DELETE,OPTIONS" />
        <add name="Access-Control-Allow-Headers" value="Content-Type" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>

警惕通配符的价值，你应该将其设置为你的网站将被托管的域名。

Be wary of the wildcard value, you should really set this to the domain name that your site will be hosted on.

这篇关于IIS劫持CORS preflight OPTIONS请求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！