何时使用 401 与何时使用 302答案

【问题标题】：When to 401 vs when to 302何时使用 401 与何时使用 302
【发布时间】：2014-05-21 14:15:35
【问题描述】：

我正在开发一个基于 Rails REST 的网站，并且正在为控制器编写功能测试。作为一个基于 REST 的应用程序，我使用了几个 HTTP 动词，GET、POST、PUT、DELETE 等。

我注意到我对匿名用户的 401 和 302 HTTP 响应代码的应用程序不一致。有时，当他们请求需要身份验证的资源时，我会返回 401 Unauthorized。其他时候，我返回 302 并将它们重定向到登录页面。

这里有我应该遵循的标准吗？什么时候应该使用 401？我什么时候应该重定向到登录页面？例如，

或者，这可能只是意见问题，是我需要自己选择和执行的约定。

【问题讨论】：

【解决方案1】：

当我阅读RFC 时，请求需要身份验证的资源的未经身份验证的用户应该始终收到401 Unauthorized。来自 RFC：

302 Found: 请求的资源暂时驻留在不同的 URI 下。

401 Unauthorized：请求需要用户认证。

显然302 不能正确描述您的情况，而401 可以。

【讨论】：

是的。严格来说这是正确的。但是，这并不实用。我相信 SO 上的大多数人都知道，当用户尝试访问受保护的资源时，网站将用户重定向到登录页面是一种常见的做法。这正是我想要对我的网站做的事情。简单地说，“不，未授权”对我来说并不合适。我也不希望搜索引擎抓取我的整个网站并在每个 URL 上查看登录表单。
如果您已经决定了答案，我不确定您为什么要问这个问题。无论如何，始终执行某事要比在某些情况下返回 401 而在其他情况下返回 302 要好得多。
我还没有决定答案。听起来你正在建立一些我没有的联系。这就是我问这个问题的原因。
我刚刚编辑了这个问题。也许更新会澄清我在哪里寻求帮助。
302 问题上的 AJAX 重定向是您应该始终使用 401 的原因。如果我正确地阅读了您的问题，您有时想返回 302，有时返回 401。这比总是返回 302 更糟糕 - 客户端必须编写错误处理逻辑来以不同的方式处理不同类型的请求，并且他们必须记住您所做的任何选择，而不是遵循既定的约定。如果您想要重定向，请在请求返回 401 时将其构建到客户端。您使用了 REST 标签，所以我给出了 REST 答案。你当然可以为所欲为！

【解决方案2】：

我不知道搜索引擎是否会索引 401 页面。

理想情况下，对于未经身份验证的用户的受限页面： 401状态码并显示登录表单。

对于仍然不允许的经过身份验证的用户： 403 和“未授权”页面。

对于登录页面： 200 OK 并显示登录表单。

【讨论】：