http-authentication - 多个方案的 WWW-Authenticate 的分隔符是什么？

Question

我已通读 RFC 2617如果支持多种方案，则无法在那里或其他任何地方找到分隔符。例如，假设支持 Basic 和 Digest。我知道它可能会以这种方式出现:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic
WWW-Authenticate: Digest

但我也读过，两者都可以列为一行，但没有人展示过示例或描述要使用的分隔符。我已经看到警告可以在单个方案中使用逗号:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest param1="foo", param2="bar"

我还读到，如果在一个方案中使用逗号，则其他方案必须放在单独的行上。所以我想在上面的例子中，如果我们添加 Basic 它会是这样的:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest param1="foo", param2="bar"
WWW-Authenticate: Basic

这很简单。但现在假设你只有一行

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Scheme stuff, morestuff, more stuff

那是哪个？这是一个以逗号分隔的方案列表，还是一个带有几个参数的方案？

Answer 1

据我所知，the spec在这个问题上下注。第 1.2 节指出:

Note: User agents will need to take special care in parsing the WWW-
Authenticate or Proxy-Authenticate header field value if it contains
more than one challenge, or if more than one WWW-Authenticate header
field is provided, since the contents of a challenge may itself
contain a comma-separated list of authentication parameters.

我想我们可以把特殊照顾翻译成祝你好运的家伙。

务实
实际上，我怀疑多个方案意味着一个人应该使用多个 wwww-authenticate标题。方案是可扩展的；例如，如果我想变得险恶，我可以想出一个名为“草莓”或“不透明”的方案。鉴于此，在没有某种“方案终止”分隔符的情况下解析单行并没有真正的好方法。

W3C 讨论
你不是第一个提出这个问题的人。那里 was a discussion在 W3C 邮件列表中。海报上写道:

I wasn't questioning the need to provide multiple challenges in a single response. I was only questioning the wisdom in allowing multiple challenges in a single header field, given the odd combination of separators it creates.

其他一些讨论当前问题和可能感兴趣的 future 行动的主题:

root of above thread

Backwards definition of authentication header

#342 WWW-Authenticate ABNF slightly ambiguous

WWW-Authenticate ABNF is ambiguous

future http 2 - Multi-legged Authentication for HTTP Multiplexing

如果只是...
并不是说我有胃口，但是可以深入研究 chromimum、firefox 和 webkit 代码，看看这些社区是如何处理这个问题的。