重定向到登录页面时正确的 HTTP 状态代码是什么？

当用户未登录并尝试访问需要登录的页面时，重定向到登录页面的正确 HTTP 状态代码是什么？

我问是因为没有一个W3C 规定的 3xx 响应代码 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html seem以满足要求：

10.3.1 300多项选择

请求的资源对应于 一组表示中的任何一个， 每个都有自己特定的位置， 和代理驱动的谈判 信息（第 12 条）正在 提供以便用户（或用户 代理）可以选择首选 表示并重定向其 请求到该位置。

除非是 HEAD 请求，否则 响应应该包含一个实体 包含资源列表 特征和位置来自 用户或用户代理可以 选择最合适的一个。这 实体格式由 Content-Type 中给出的媒体类型 标头字段。取决于 的格式和功能

用户代理，选择最 可以进行适当的选择 自动地。然而，这 规范没有定义任何 此类自动选择的标准。

如果服务器有首选选择 代表，它应该包括 具体的 URI 位置字段中的表示； 用户代理可以使用位置字段 自动重定向的值。这 除非另有说明，响应是可缓存的 否则。

10.3.2 301永久移动

请求的资源已 分配一个新的永久 URI 和任何 未来对该资源的引用 应使用返回的 URI 之一。 具有链接编辑功能的客户端 应该自动重新链接 对 Request-URI 的引用之一 或更多返回的新引用 在可能的情况下由服务器执行。这 除非另有说明，响应是可缓存的 否则。

应给出新的永久 URI 通过响应中的位置字段。 除非请求方法是HEAD， 响应的实体应该 包含一个简短的超文本注释 指向新 URI 的超链接。

如果收到 301 状态码 对 GET 以外的请求的响应 或 HEAD，用户代理不得 自动重定向请求 除非能够得到相关部门的确认 用户，因为这可能会改变 提出请求的条件 发布。

  Note: When automatically redirecting a POST request after
  receiving a 301 status code, some existing HTTP/1.0 user agents
  will erroneously change it into a GET request.

10.3.3 找到 302

请求的资源驻留在 暂时使用不同的 URI。 由于重定向可能会改变 有时，客户应该 继续使用Request-URI 未来的请求。此回应仅 如果由 a 指示则可缓存 Cache-Control 或 Expires 标头字段。

临时 URI 应由以下给出 响应中的位置字段。 除非请求方法是HEAD， 响应的实体应该 包含一个简短的超文本注释 指向新 URI 的超链接。

如果收到 302 状态码 对 GET 以外的请求的响应 或 HEAD，用户代理不得 自动重定向请求 除非能够得到相关部门的确认 用户，因为这可能会改变 提出请求的条件 发布。

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed
  to change the method on the redirected request.  However, most
  existing user agent implementations treat 302 as if it

是 303 响应，对位置字段值执行 GET，不管 原始请求方法。状态码 303 和 307 有 已为希望明确表明哪些服务器添加 预期客户会有什么样的反应。

10.3.4 303 查看其他

对请求的响应可以是 在不同的 URI 下找到并且应该 使用 GET 方法检索 该资源。这个方法存在 主要是为了允许输出 POST 激活的脚本来重定向 用户代理到选定的资源。这 新 URI 不是替代引用 对于最初请求的资源。 303 响应不得被缓存， 但对第二个的回应 （重定向）请求可能是 可缓存。

不同的 URI 应由以下方式给出 响应中的位置字段。 除非请求方法是HEAD， 响应的实体应该 包含一个简短的超文本注释 指向新 URI 的超链接。

  Note: Many pre-HTTP/1.1 user agents do not understand the 303
  status. When interoperability with such clients is a concern, the
  302 status code may be used instead, since most user agents react
  to a 302 response as described here for 303.

10.3.5 304 未修改

如果客户端执行了 有条件的 GET 请求和访问是 允许，但该文件尚未通过 修改后，服务器应该响应 与此状态代码。 304 响应不得包含 消息体，因此总是 由第一个空行终止 在标题字段之后。

响应必须包括 以下标头字段：

  - Date, unless its omission is required by section 14.18.1 If a

无时钟源服务器遵守这些 规则，代理和客户端添加 他们自己的回复日期 没有收到（已经 由 [RFC 2068] 部分指定 14.19），缓存将正确运行。

  - ETag and/or Content-Location, if the header would have been sent
    in a 200 response to the same request
  - Expires, Cache-Control, and/or Vary, if the field-value might
    differ from that sent in any previous response for the same
    variant If the conditional GET used a strong cache validator (see

第 13.3.3 节），响应应该 不包括其他实体标题。 否则（即条件 GET 使用了弱验证器），响应 不得包含其他实体标头； 这可以防止之间的不一致 缓存实体主体并更新 标头。

如果 304 响应指示实体 当前未缓存，则缓存 必须忽略响应并重复 不带条件的请求。

如果缓存使用收到的 304 响应更新缓存条目， 缓存必须更新条目以反映 中给出的任何新字段值 回复。

10.3.6 305使用代理

请求的资源必须是 通过指定的代理访问 位置字段。位置字段 给出代理的 URI。这 收件人应重复此操作 通过代理的单个请求。 305 响应必须仅由生成 原始服务器。

  Note: RFC 2068 was not clear that 305 was intended to redirect a
  single request, and to be generated by origin servers only.  Not
  observing these limitations has significant security consequences.

10.3.7 306（未使用）

306 状态码用于 先前版本的规范， 不再使用，代码是 预订的。

10.3.8 307临时重定向

请求的资源驻留在 暂时使用不同的 URI。 由于重定向可能会改变 有时，客户应该 继续使用Request-URI 未来的请求。此回应仅 如果由 a 指示则可缓存 Cache-Control 或 Expires 标头字段。

临时 URI 应由以下给出 响应中的位置字段。 除非请求方法是HEAD， 响应的实体应该 包含一个简短的超文本注释 指向新 URI 的超链接，因为 许多 HTTP/1.1 之前的用户代理没有 了解 307 状态。所以， 该注释应该包含 用户所需的信息 在新的请求上重复原来的请求 URI。

如果收到 307 状态码 对 GET 以外的请求的响应 或 HEAD，用户代理不得 自动重定向请求 除非能够得到相关部门的确认 用户，因为这可能会改变 提出请求的条件 发布。

我现在使用 302，直到我发现the正确答案。

更新及结论：

HTTP 302 更好，因为它与客户端/浏览器具有最佳兼容性。

我会说第303章 看看其他罢工>302 找到：

请求的资源暂时驻留在不同的 URI 下。自重定向以来有时可能会改变，客户端应该继续使用 Request-URI 来进行未来的请求。仅当由 Cache-Control 或 Expires 标头字段指示时，此响应才是可缓存的。

我认为最适合登录页面。我最初考虑303 see other这也同样有效。经过一番思考，我会说302 Found更合适，因为请求的资源was发现只要再经过一个页面就可以访问了。默认情况下不会缓存响应，这也很好。