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

据我所知,该规范的平底船上的问题.第1.2节规定:

注意:如果WWW-Authenticate 或Proxy-Authenticate标头字段值包含 多个质询,或者如果提供了多个WWW-Authenticate标头 字段,则用户代理需要特别注意解析WWW-
Authenticate或Proxy-Authenticate标头字段值

,因为挑战的内容可能本身
包含以逗号分隔的身份验证参数列表.

我想我们可以将特别关注转化为幸运的一步.

实用主义
作为一个实际问题,我怀疑多个方案意味着应该使用多个wwww-authenticate标题.方案是可扩展的; 例如,如果我想要阴​​险,我可以想出一个叫做"草莓"或"不透明"的方案.鉴于此,如果没有某种"方案终止"分隔符,就没有一种很好的方法来解析单行代码.

W3C讨论
您不是第一个提出这个问题的人.有是一个讨论的W3C邮件列表上.海报说:

我并没有质疑是否需要在单一响应中提供多个挑战.考虑到它创建的分隔符的奇怪组合,我只是质疑在单个标题字段中允许多个挑战的智慧.

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

• 以上线程的根
• 向后定义身份验证标头
• #342 WWW-Authenticate ABNF略显含糊
• WWW-Authenticate ABNF含糊不清
• 未来的http 2 - HTTP多路复用的多线认证

如果只是......
不是说我有胃,但是人们可以通过chromimum,firefox和webkit代码来了解这些社区如何处理这个问题.