我无法找到信息来解释如果对预检请求的响应或对实际 CORS 请求的响应省略 Access-Control-Allow-Headers 会发生什么情况。我注意到，有几个网站表示，当请求包含 Access-Control-Request-Headers 时，需要此标头。
我想允许 CORS 使用任何标头访问我的 API，所以我想知道省略此标头是否可以做到这一点并允许所有标头。
我的 API 要求您发送包含 OAuth 令牌的 Authorization 标头，通常客户端也会发送 cookie。有些网站表示，在 Access-Control-Allow-Credentials 时使用 * 表示 Access-Control-Allow-Headers 仅充当通配符是假。
这似乎让我陷入了困境，因为我希望 CORS 请求包含凭据（Authorization 标头和 cookie），但我也想允许所有标头。我怎样才能做到这一点？
第二个问题是为什么我想将请求限制为允许的标头集？就我而言，API 是 GET，它不会对服务器进行任何更改。我希望允许的来源始终能够检索此信息。在什么情况下它们包含的标头会发挥作用？
I’m having trouble finding information explaining what happens if the response to a preflight request or the response to the actual CORS request omits Access-Control-Allow-Headers. I have noticed that several sites say this header is required when the request includes Access-Control-Request-Headers.
I would like to allow CORS access to my API with any headers, so I’m wondering if omitting this header will do just that and allow all headers.
My API requires that you send an Authorization header containing an OAuth token and typically the client will also send a cookie. There are sites that say that using * for Access-Control-Allow-Headers only acts as a wildcard when Access-Control-Allow-Credentials is false.
This seems to put me in a bind since I want the CORS request to include credentials (the Authorization header and a cookie) but I also want to allow all headers. How can I make this work?
A secondary question is why would I want to restrict the request to an allowed set of headers? In my case the API is a GET which makes no changes on the server. I want allowed origins to always be able to retrieve this information. Under what circumstances would the headers they include play into that?
发布评论
评论（1）
这些站点是正确的：如果前飞行请求包含
access-control-Request-Headers标题，则至少必须包含access-control-allow的响应-Newers标题或CORS前飞行将失败。 CORS Preflight成功所需的实际标头值将因跨越请求中指定的标头名称而有所不同。不，省略
访问控制者-Allow-HALE-HALE-HALEDER标题在响应前的请求中不算是通过。关闭，但不精确。相反，如果您使用
access-control-allow-credentials：true，则不能将通配符用于access-control-walla-alleaders。参见 https://fetch.whatwg.whatwg.org/#http-new -header-syntax在这种情况下，您不能使用通配符。您只有一种方法：将所有标题名称列出在“前飞行请求”的
access-control-request-Headers标题中，并在响应的access-controll-alleaders 标题。我可能缺少一些东西，但是如果允许的起源是有限的，我认为这不会有问题。但是，如果您允许任意起源，则可能不应允许在身份验证的端点上任意标题。特别是，允许
授权任意起源为客户端，分布式的野蛮人代币（或任何授权通常包含）打开了大门；在Those sites are correct: if the preflight request contains an
Access-Control-Request-Headersheader, then the response to that request must, at the very least, contain anAccess-Control-Allow-Headersheader, or CORS preflight will fail. The actual header value required for CORS preflight to succeed will differ on the basis of which header names were specified in the preflight request.No, omitting the
Access-Control-Allow-Headersheader in the response to the preflight request does not count as a pass.Close, but imprecise. Rather, you cannot use the wildcard for
Access-Control-Allow-Headersif you useAccess-Control-Allow-Credentials: true. See https://fetch.spec.whatwg.org/#http-new-header-syntaxIn that case, you cannot use the wildcard. You only have one way: take all the header names listed in the preflight request's
Access-Control-Request-Headersheader and reflect them in the response'sAccess-Control-Allow-Headersheader.I may be missing something, but I don't think this is problematic if the set of allowed origins is finite. However, if you allow arbitrary origins, you probably shouldn't allow arbitrary headers on authenticated endpoints. In particular, allowing the
Authorizationfor arbitrary origins opens the door to client-side, distributed brute-force of Bearer tokens (or whatever theAuthorizationnormally contains); more about that in https://github.com/whatwg/fetch/issues/251#issuecomment-209265586