Access-Control-Allow-Origin 标头必须包含方案吗？

Question

我在使用 CORS 定义时遇到了一些问题，我有一个问题（一般来说不是关于 CORS - 那个我很好 - 只是关于官方规范和用法）：

根据 IETF，如果传递了 Origin 标头并且它是 URL，则该 URL 必须完全序列化，并且必须包括方案和主机（以及可选的端口）。来自https://www.rfc-editor.org/rfc/rfc6454#section-7.1：

The Origin header field has the following syntax:

origin              = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
origin-list         = serialized-origin *( SP serialized-origin )
serialized-origin   = scheme "://" host [ ":" port ]
                   ; <scheme>, <host>, <port> from RFC 3986

至少，我认为我理解正确。

IETF 也说 Access-Control-Allow-Origin 标头的格式必须遵循相同的格式。来自http://www.w3.org/TR/cors/#access-control-allow-origin-response-header：

Access-Control-Allow-Origin = "Access-Control-Allow-Origin" ":" origin-list-or-null | "*"

并链接到 Origin 标题页。

但是，我已经看到了许多示例（在 SO 和其他地方），它们显示了 ACAO 标头没有该方案（即不是 Origin 标头的精确“镜像”），例如他们表明这是在请求中传递的：

Origin: http://www.example.com

这是“正确”的回应：

Access-Control-Allow-Origin: www.example.com

那么 ACAO 标头有效吗？我认为 ACAO 标头必须是 Origin 标头值（或“*”或“null”）的精确镜像。

如果我用一个不包含该方案的 ACAO 标头进行响应，用户代理是否应该接受它？还是在 UA-by-UA 的基础上？如果 Origin 包含端口号怎么办 - 我是否需要在 ACAO 响应标头中包含该端口号，无论是否有方案？

Answer 1

正如你所提到的，RFC 6454 定义了一个来源的语法，没有歧义：

origin              = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
origin-list         = serialized-origin *( SP serialized-origin )
serialized-origin   = scheme "://" host [ ":" port ]

和CORS W3C recommandation 明确引用相同的定义。

Access-Control-Allow-Origin = "Access-Control-Allow-Origin" ":" origin-list-or-null | "*"

所以下面的标题无效

Access-Control-Allow-Origin: www.example.com

并且不得被用户代理接受

当生成一个 Origin 头域时，用户代理必须满足 以下要求：

语法中的每个序列化起源产生式都必须是 来源的 ascii 序列化。

由于same-origin policy：

，这一点尤为重要

同源策略是安全的基石之一 许多用户代理，包括网络浏览器。

关于端口号问题的第二部分，ASCII serialization of an origin algorithm 表示：

5. 如果源三元组的端口部分不同于 由方案部分给出的协议的默认端口 原点三元组：

  1.  Append a U+003A COLON code point (":") and the given port, in

       base ten, to result.