Access-Control-Allow-Methods
用法
在发送使用非简单方法的跨源请求之前,浏览器会发出一个预检 OPTIONS 请求。预检中的 Access-Control-Request-Method 头指明客户端计划使用的方法。服务器以 Access-Control-Allow-Methods 作答,确认目标资源接受哪些方法。
简单方法(GET、HEAD 和 POST)在 CORS 协议中始终被允许,严格来说无需在此列出。显式列出它们是常见做法,能让服务器策略一目了然。
多个方法以逗号分隔的列表形式出现。
方法名称列表
一组以逗号分隔的 HTTP 方法名称,表示服务器接受它们进行跨源访问。
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
*(通配符)
对于不带凭据的请求,星号充当通配符,允许任意方法。
Access-Control-Allow-Methods: *
注意
对于带凭据的请求,通配符 * 会被当作字面字符串而非通配符处理。当存在凭据时,每个允许的方法都必须显式列出。
示例
一个预检请求询问是否允许 PUT 方法。服务器确认了多个方法。
请求
OPTIONS /api/resource/42 HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: PUT
响应
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Max-Age: 7200
一个更严格的服务器只允许 GET 和 POST。
Access-Control-Allow-Methods: GET, POST
故障排查
与 HTTP 方法相关的预检失败会在服务器处理预期操作之前阻止实际的跨源请求。
控制台显示”Method PUT is not allowed by Access-Control-Allow-Methods in preflight response.”。服务器未在 Access-Control-Allow-Methods 值中包含所请求的方法。请将缺失的方法添加到预检响应中。在 nginx 中:add_header Access-Control-Allow-Methods “GET, POST, PUT, DELETE, PATCH”; 在 Apache 中:Header set Access-Control-Allow-Methods “GET, POST, PUT, DELETE, PATCH”
预检响应完全缺少该头。OPTIONS 处理器存在,但没有返回 Access-Control-Allow-Methods。请确认预检路由在设置 Access-Control-Allow-Origin 和 Access-Control-Allow-Headers 的同时也设置了该头。缺少方法头会导致浏览器拒绝任何非简单方法。
通配符 * 在带凭据的请求中不起作用。当 Access-Control-Allow-Credentials 为 true 时,通配符会被当作字面字符串 * 处理,无法匹配任何方法。在带凭据的配置中请显式列出每个允许的方法。
服务器在预检期间返回 405 Method Not Allowed。服务器没有处理目标 URL 的 OPTIONS 的路由,因此请求命中了一个拒绝该方法的兜底处理。请为该路由添加 OPTIONS 处理器。在 Express 中:app.options(‘/api/resource’, cors())。在 Django 中,django-cors-headers 中间件安装后会自动处理 OPTIONS。在 nginx 中,添加 if ($request_method = OPTIONS) 块,或使用 limit_except 在该 location 上允许 OPTIONS。
框架自动处理 OPTIONS 但未包含 CORS 头。某些框架会以 200 或 204 和一个列出所支持方法的普通 Allow 头来响应 OPTIONS,但不附带任何 CORS 头。浏览器会将其视为失败的预检,因为缺少 Access-Control-Allow-Methods。请配置 CORS 中间件在框架内置处理器之前拦截 OPTIONS 请求。在 Spring Boot 中,注册一个 CorsFilter bean。在 ASP.NET 中,在 app.UseRouting() 之前使用正确的策略调用 services.AddCors()。