重定向到登录页面时，正确的 HTTP 状态代码是什么? [英] What is correct HTTP status code when redirecting to a login page?

问题描述

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

我之所以这么问是因为没有一个 W3C 规定的 3xx 响应代码 似乎符合要求:

<块引用>

10.3.1 300 多项选择

请求的资源对应一组表示中的任何一个，每个都有自己的特定位置，和代理驱动的协商信息(第 12 节)正在提供以便用户(或用户代理)可以选择一个首选表示并重定向其请求到那个位置.

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

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

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

10.3.2 301 永久移动

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

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

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

 注意:当自动重定向 POST 请求后接收 301 状态代码，一些现有的 HTTP/1.0 用户代理将错误地将其更改为 GET 请求.

发现 10.3.3 302

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

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

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

 注:RFC 1945 和 RFC 2068 指定不允许客户端更改重定向请求的方法.然而，大多数现有的用户代理实现将 302 视为

是 303响应，对 Location 字段值执行 GET，不管原始请求方法.状态码 303 和 307 有为希望明确说明哪些服务器添加了期待客户的反应.

10.3.4 303 查看其他

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

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

 注意:许多 HTTP/1.1 之前的用户代理不理解 303地位.当与此类客户端的互操作性是一个问题时，可以使用 302 状态码来代替，因为大多数用户代理都会做出反应到 302 响应，如此处针对 303 所述.

10.3.5 304 未修改

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

响应必须包括以下标题字段:

 - 日期，除非第 14.18.1 节要求省略

无时钟源服务器遵守这些规则，代理和客户端添加他们自己的任何回应的日期没有收到(就像已经由 [RFC 2068] 部分指定14.19)，缓存将正常运行.

 - ETag 和/或 Content-Location，如果标头已经发送在对同一请求的 200 响应中- 过期、缓存控制和/或变化，如果字段值可能与之前针对相同的任何响应发送的不同变体 如果条件 GET 使用了强大的缓存验证器(请参阅

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

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

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

10.3.6 305 使用代理

请求的资源必须是通过给定的代理访问位置字段.位置字段给出代理的 URI.这预计收件人会重复此操作通过代理的单一请求.305响应只能由源服务器.

 注意:RFC 2068 并不清楚 305 旨在重定向单个请求，并且仅由源服务器生成.不是遵守这些限制会产生重大的安全后果.

10.3.7 306(未使用)

306 状态代码用于先前版本的规范，不再使用，代码为保留.

10.3.8 307 临时重定向

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

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

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

我现在使用 302，直到我找到正确答案.

更新&结论:

HTTP 302 更好，因为它与客户端/浏览器的兼容性最好.

解决方案

我想说 303 see other 302 Found:><块引用>

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

我认为最适合登录页面.我最初认为 303 see other 也能正常工作.经过一番思考，我会说 302 Found 更合适，因为请求的资源 was 找到了，在它可以访问之前只需要经过另一个页面.默认情况下，响应不会被缓存，这也很好.

When a user is not logged in and tries to access a page that requires login, what is the correct HTTP status code for a redirect to the login page?

I am asking because none of the 3xx response codes set out by the W3C seem to fit the requirements:

10.3.1 300 Multiple Choices

The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.

Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of

the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.

If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise.

10.3.2 301 Moved Permanently

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

  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 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

  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

were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

10.3.4 303 See Other

The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

  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 Not Modified

If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.

The response MUST include the following header fields:

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

clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly.

  - 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

section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.

If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.

If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.

10.3.6 305 Use Proxy

The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers.

  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 (Unused)

The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.

10.3.8 307 Temporary Redirect

The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.

If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

I'm using 302 for now, until I find the correct answer.

Update & conclusion:

HTTP 302 is better since its known to have best compatibility with clients/browsers.

解决方案

I'd say 303 see other 302 Found:

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

fits a login page most closely in my opinion. I initially considered 303 see other which would work just as well. After some thought, I'd say 302 Found is more fitting because the requested resource was found, there just is another page to go through before it can be accessed. The response doesn't get cached by default which is fine as well.

这篇关于重定向到登录页面时，正确的 HTTP 状态代码是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！