在“未验证”和“未授权”情况下使用什么 HTTP 代码？

Question

我读到，当用户：时必须使用“401未经授权”

代码：

1. 未登录，但需要登录（“未验证”）；
2. 已登录，但他的个人资料不允许查看该网址（“未授权”）；

根据 RFC，在这两种情况下服务器都必须返回

401

代码。 但我需要在我的 ajax 请求中区分。

有人有解决这个问题的建议吗？

注意：我不想使用

403 Forbidden

代码，因为根据 RFC，在 403

"Authorization will not help"

中。

Answer 1

除非您打算使用 HTTP 身份验证，否则正确的响应是 403（“禁止”）。

响应代码 401 会触发浏览器显示密码对话框，然后使用

Authorization

标头以及用户提供的密码数据重新提交相同的请求。这可能不是您想要的行为。

不要太执着于 RFC 中的解释——您真正需要注意的是各种响应代码对浏览器和搜索引擎的副作用。

至于

"Authorization will not help"

位，在本例中这是正确的，因为使用 HTTP 授权（具体指

Authorization

标头）实际上没有帮助。

403 响应告诉浏览器用户无权发出该请求，浏览器不应尝试收集身份验证数据并重新提交请求。这正是您想要的回应。

Answer 2

我相信403是正确的。我们可能需要调整规范中的语言来明确这一点。

Answer 3

除了状态代码之外，您还应该传递自定义标头以满足应用程序特定需求。

我相信当前的做法是在自定义标题前添加

X-

更新，2012 年 8 月：

摘自评论中发布的

RFC 3864（日期为 2004 年 9 月）：

在某些情况下（尤其是 HTTP [24]），标头语法和用法是 为特定应用重新定义。 [...] 在某些情况下，相同的字段名称可能会以不同的方式指定（通过 不同的文档）用于不同的应用协议。 [...] 我们需要适应特定于应用程序的领域，同时希望 认识并促进（在适当情况下）其他领域的共性 跨多个应用程序。

在最近的 RFC（

6648，日期为 2012 年 6 月）中，他们专门解决了 X-

 标头。

不推荐使用新定义参数的“X-”约定 应用协议，包括已建立的新参数 协议。 [...] 不建议反对私人的做法， 局部的、初步的、实验性的或特定于实施的 参数，仅反对使用“X-”和类似的结构 此类参数的名称。

重要的是要注意的是，虽然

X-

是

特别指出的，但它们仍然隐式地容忍自定义标头作为传输信息的方式。应用程序特定的前缀 (MyApp-

) 可能更适合避免与任何其他标头发生冲突。

另请参阅：

几年前在 HTTP 响应中使用“X-”标头是否安全。

Answer 4

参考

）：

401=用户未登录，但需要登录

• 401.1 = 用户尝试登录，但其凭据无效。
• 401.3 = 用户的凭据有效，但用户无权查看资源。