Tomcat CORS过滤器：为什么“Access-Control-Allow-Headers”中的标题默认列表是如此随意限制？

Question

Tomcat（7.0.50）带来了一个实现CORS规范的特殊过滤器。在此过滤器中，默认的允许标头列表如下：

起源，接受，X-请求-随着，内容类型，访问控制请求-方法，访问控制请求报头。

我知道我可以使用filter参数“cors.allowed.headers”替换该列表，并指定我自己的标题列表。我知道。但我有以下问题：

• 创建此过滤器时，为什么列表中填充了这个 - 标题较短的标题列表？为什么这些标题而不是其他？例如，为什么不是列表中的“缓存控制”标题？这个名单是如何选择的？
• 如果我想定义一个更完整的列表，我应该包含哪些标题？有许多标题要考虑！
• 我可以使用“*”而不是指定列表吗？这是CORS规范允许的吗？
• 我知道CORS规范定义了这种列表，但是......为什么这有必要？为什么我们不能只接受飞行前OPTIONS步骤中的任何标题，而不是返回403（Forbiden），如果客户端请求的标题中至少有一个不在允许的标题列表中？
• 为什么过滤器中没有选项可以执行以下操作： response.setHeader（＆＃34; Access-Control-Allow-Headers＆＃34;，request.getHeader（＆＃34; Access-Control-Request-Headers＆＃34;）？

我很困惑。我的API的一个用户在飞行前步骤中在“访问控制请求标头”列表中发送了“缓存控制”标头，并收到HTTP 403错误状态。我可以将此标头添加到列表中（使用“cors.allowed.headers”过滤器参数）。但是，下次某个客户端发送另一个不在列表中的标头呢？

布赖恩

Answer 1

我花了好几个小时试图理解CORS规范（http://www.w3.org/TR/cors/）。它真的很难理解。

cors.allowed.headers列表指定实际请求中允许哪些标头。

在预检请求中，客户端通过“Access-Control-Request-Headers”字段告诉服务器，资源必须允许哪些标头。如果其中一个值不在cors.allowed.headers列表中，则拒绝该请求。此行为在CORS规范中指定。

我认为Access-Control-Request-Headers用于检查所请求的资源是否真的支持这些标头。如果不是，则不能满足实际请求。事实上，Tomcat返回“FORBIDDEN”可能是一个实现细节。

如果您需要上一点中提到的某些特殊功能，您可能需要实现自己的CORS过滤器。