你保证OPTIONS
请求被您的应用程序代码来处理和系统不是其它部分到达您的应用程序代码之前,您可以尝试添加以下到您的web.config
:
<system.webServer>
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
您可能还需要包括:
<add name="OPTIONSVerbHandler" path="*" verb="OPTIONS"
modules="IsapiModule" requireAccess="None"
scriptProcessor="C:\Windows\System32\inetsrv\asp.dll"
resourceType="Unspecified" />
见一请致电IIS hijacks CORS Preflight OPTIONS request。
,或者甚至只是这样的:
<add name="OPTIONSVerbHandler" path="*" verb="OPTIONS"
modules="ProtocolSupportModule" requireAccess="None" />
如果这些方法都对自己的作品,然后在global.asax
或其他代码,你可以尝试:
if (filterContext.HttpContext.Request.HttpMethod == "OPTIONS")
{
filterContext.HttpContext.Response.Flush();
}
...或其他一些变异的研究例如:
if (Request.Headers.AllKeys.Contains("Origin", StringComparer.OridinalIgnoreCase)
&& Request.HttpMethod == "OPTIONS") {
Response.Flush();
}
无论您使用什么特定的代码,点是:
- 确保
OPTIONS
请求实际上陷入/你的应用程序处理的代码没有抓到/曾达到您的应用程序代码
- 使之前由系统的其他部分进行处理确保你有明确的处理在应用程序代码
OPTIONS
请求
- 使
OPTIONS
处理在应用程序代码只是做Response.Flush()
或者另一种方法,我不知道是有关您的情况编码,但我会提到,以防万一:
public HttpResponseMessage Options()
{
var response = new HttpResponseMessage
{
StatusCode = HttpStatusCode.OK
};
return response;
}
嗯,你有没有试过只发送请求作为POST而不是OPTIONS?我想当你做CORS请求时,浏览器会在后台为你选择一些东西(尽管我可能会误会)。 – victor
POST请求本身起作用,但浏览器首先发送OPTIONS请求并失败,所以它永远不会发送POST。 – SZH
[EnableCors(“https://example.com”,“*”,“post,options”)]? 告诉操作接受OPTIONS请求以及POST – victor