Access-Control-Allow-Headers 头
Baseline 广泛可用 *
HTTP Access-Control-Allow-Headers 响应头用于响应预检请求，指示在实际请求期间可以使用的 HTTP 头。如果预检请求包含 Access-Control-Request-Headers，则此头是必需的。
注意： CORS 安全列表请求头始终被允许，并且通常不会在 Access-Control-Allow-Headers 中列出，除非需要规避额外的安全列表限制。
语法
Access-Control-Allow-Headers: <header-name>
Access-Control-Allow-Headers: <header-name>, <header-name>
Access-Control-Allow-Headers: *
指令
<header-name>-
支持的请求头的名称。该头可以列出任意数量的头，以逗号分隔。
*(通配符)-
任意头。值
*仅对于不带凭据的请求（不带 HTTP cookie 或 HTTP 认证信息的请求）作为特殊的通配符值。在带凭据的请求中，它被视为字面头名称*，没有特殊语义。Authorization头不接受通配符，并且始终需要明确列出。
示例
实现自定义头
下面是 Access-Control-Allow-Headers 头的一个示例。它指示服务器支持 CORS 请求中的自定义头 X-Custom-Header，此外还支持CORS 安全列表请求头。
Access-Control-Allow-Headers: X-Custom-Header
支持多个头
此示例展示了 Access-Control-Allow-Headers 在指定支持多个头时的情况。
Access-Control-Allow-Headers: X-Custom-Header, Upgrade-Insecure-Requests
绕过 CORS 安全列表头的额外限制
尽管CORS 安全列表请求头始终被允许，并且通常不需要在 Access-Control-Allow-Headers 中列出，但无论如何列出它们将规避适用的额外限制。
Access-Control-Allow-Headers: Accept
处理预检请求
让我们看一个涉及 Access-Control-Allow-Headers 的预检请求示例。
Request
首先，预检请求是一个 OPTIONS 请求，它包含以下三个预检请求头的某种组合：Access-Control-Request-Method、Access-Control-Request-Headers 和 Origin。
下面的预检请求告诉服务器，我们希望发送一个 CORS GET 请求，其中包含 Access-Control-Request-Headers 中列出的头（Content-Type 和 X-Requested-With）。
OPTIONS /resource/foo
Access-Control-Request-Method: GET
Access-Control-Request-Headers: content-type,x-requested-with
Origin: https://foo.bar.org
Response
如果预检请求指示的 CORS 请求被授权，服务器将以包含允许的源、方法和头的消息响应预检请求。在下面，我们看到 Access-Control-Allow-Headers 包含了所请求的头。
HTTP/1.1 200 OK
Content-Length: 0
Connection: keep-alive
Access-Control-Allow-Origin: https://foo.bar.org
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Allow-Headers: Content-Type, x-requested-with
Access-Control-Max-Age: 86400
如果请求的方法不受支持，服务器将响应错误。
规范
| 规范 |
|---|
| Fetch # http-access-control-allow-headers |
浏览器兼容性
加载中…