推荐的 CORS 允许和公开标头

Question

enable-cors.org nginx config 建议对Access-Control-Allow-Headers 和Access-Control-Expose-Headers 使用以下值。但是除了Custom headers and headers various browsers *should* be OK with but aren't之外，没有太多解释为什么推荐这些。如果我的应用程序不需要其中一些 API 请求，我宁愿不要为每个 API 请求增加有效负载。

我知道我可以删除它们并等待某些东西中断，但我希望了解一些关于为什么/如何选择它们的背景，以便我可以就我的申请是否需要它们做出更有根据的决定。即是否建议他们支持我的应用程序不需要支持的浏览器？

访问控制允许标头：DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range

Access-Control-Expose-Headers：DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range

对于Allow-Headers，我可以理解他们中的大多数人为什么要发送它们。 X-CustomHeader 不过是个怪人。此外，我在 Chrome 上进行了测试，即使 User-Agent 未被明确允许，chrome 仍会发送它。这意味着添加这些选项是为了实现我的应用可能不需要的浏览器兼容性。

对于Expose-Headers，客户端需要读取哪些标头似乎是非常特定于应用程序的。为什么客户需要阅读User-Agent、DNT 或X-Requested-With？它们包含供服务器使用的信息，而不是客户端。此外，Cache-Control 和 Content-Range 已经是 enabled by default，所以它们在这里显得多余。

Answer 1

我最终浏览了每个标题并确定是否有必要。我编制了一份变更清单：

• Allow 和 Expose 的更改
  • 从两者中删除，因为它们是非标准标题
    • X-CustomHeader
  • 从两者中删除，因为它们是非标准和半弃用的
    • Keep-Alive
• Allow 的更改：
  • 已删除，因为它们是 响应 特定的标头（仅用于 服务器通知客户端）
    • Content-Range
  • 即使它们默认启用但仅在某些情况下仍保留 请求类型（as per MDN）：
    • Content-Type
• Expose 的更改：
  • 已删除，因为它们已默认启用 (as per MDN)
    • Cache-Control
    • Content-Type
  • 已删除，因为它们是 request 特定的标头（仅用于 客户端通知服务器）
    • DNT
    • User-Agent
    • X-Requested-With
    • If-Modified-Since
    • Range
  • 添加是因为它们看起来很有用
    • Content-Length

这给我留下了以下内容：

访问控制允许标头：DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range

Access-Control-Expose-Headers：Content-Length,Content-Range

任何 cmets 或更正将不胜感激。