C#怎么处理跨域预检请求_C# OPTIONS请求的CORS响应配置【避坑】-C#.Net教程-PHP中文网

根本原因是iis或asp.net管道在预检请求到达控制器前就拦截了options请求，因默认未放行该方法，导致直接返回405而非进入cors处理流程。

c#怎么处理跨域预检请求_c# options请求的cors响应配置【避坑】

为什么 OPTIONS 请求总返回 405 或被拦截

根本原因不是 CORS 配置漏了，而是 IIS 或 ASP.NET 管道在预检请求到达控制器前就把它拦下了。默认情况下，IIS 不允许 OPTIONS 方法通过，尤其当 Web.config 没显式放开、或 Global.asax 里没提前截获时，请求根本进不了 WebAPI 的路由层，直接 405 Method Not Allowed。

常见现象包括：

浏览器 Network 面板看到 OPTIONS 请求状态码是 405，后面没有真正的 POST/PUT 请求
即使加了 config.EnableCors()，依然报错 “Response to preflight request doesn’t pass access control check”
带自定义 Header（如 Authorization、X-Api-Key）或非简单 Content-Type（如 application/json）的请求必触发预检，但服务端没响应头

Global.asax 中 Application_BeginRequest 必须做两件事

这是绕过 IIS 拦截最直接有效的手段，必须在请求进入 MVC/WebAPI 管道前就处理掉 OPTIONS 请求。

关键点：

判断条件要严格：同时满足 Request.Headers.AllKeys.Contains("Origin") 且 Request.HttpMethod == "OPTIONS"
不能只写 Response.End() —— 它可能引发线程中止异常；推荐用 Response.StatusCode = 200; Response.End(); 或更稳妥的 Response.SuppressContent = true; Response.StatusCode = 200; Response.End();
务必确保该逻辑在 Application_BeginRequest 中，不能放在 Application_Start 或控制器里
如果项目启用了 FormsAuthentication 或其他模块，需确认它们不会在 BeginRequest 后覆盖响应

Web.config 的 customHeaders 和 handler 映射必须匹配

仅靠代码层 CORS 配置不够，IIS 层也要放行 OPTIONS 并注入必要响应头，否则预检响应会缺失关键字段。

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

在 <system.webserver></system.webserver> 节点下添加：

<httpprotocol><customheaders><add name="Access-Control-Allow-Origin" value="https://your-frontend-domain.com"></add><add name="Access-Control-Allow-Methods" value="GET,POST,PUT,DELETE,OPTIONS"></add><add name="Access-Control-Allow-Headers" value="Content-Type,Authorization,X-Requested-With"></add><add name="Access-Control-Allow-Credentials" value="true"></add></customheaders></httpprotocol><handlers><remove name="ExtensionlessUrlHandler-Integrated-4.0"></remove><add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" precondition="integratedMode,runtimeVersionv4.0" responsebufferlimit="0"></add></handlers>

注意：

Access-Control-Allow-Origin 值不能为 * 且 Access-Control-Allow-Credentials 为 true，否则浏览器拒绝响应
<handlers></handlers> 配置确保 OPTIONS 能被正确路由到 ASP.NET，避免 IIS 直接返回 405
如果部署在子目录或虚拟目录下，检查 path 是否影响匹配

EnableCorsAttribute 的 origins 参数不能写 * 当需要凭据时

很多人配置 new EnableCorsAttribute("*", "*", "*") 后仍失败，问题就出在这里 —— 只要前端设置了 withCredentials: true（比如传 Cookie 或 Authorization header），后端 Access-Control-Allow-Origin 就绝不能是通配符 *。

正确做法：

开发环境可写死：origins: "http://localhost:8080"
生产环境建议白名单校验，例如在 Application_BeginRequest 中动态读取 Origin 并比对合法域名列表，再设置响应头
若用 GlobalConfiguration.Configuration.EnableCors() 全局启用，记得它和控制器级 [EnableCors] 是叠加关系，后者优先级更高
SupportsCredentials = true 必须显式设，否则 Access-Control-Allow-Credentials: true 不会输出

真正容易被忽略的是：预检响应里缺失 Access-Control-Allow-Headers 会导致后续请求被静默拦截，而这个头在 Web.config 和代码层都要对齐 —— 前端发了什么自定义 header，后端就必须在 allow 列表里列出来，一个都不能少。