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

问题描述

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

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?

我问，因为W3C没有列出 3xx响应代码 似乎符合要求：

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

10.3.1 300多项选择

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

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.

除非是HEAD请求，否则
响应应该包含一个实体
，其中包含资源
特征和位置的列表（s来回m
用户或用户代理可以
选择最合适的一个。
实体格式由Content-Type
标头字段中给出的
媒体类型指定。根据
格式和

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.

如果服务器有一个首选的选择
表示，它应该包括
位置字段中该
表示的特定URI;
用户代理可以使用Location字段
值进行自动重定向。这个
响应是可缓存的，除非另有指示
。

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永久移动

请求的资源是
分配了一个新的永久URI，以及任何
将来对此资源的引用
应该使用返回的URI之一。
具有链接编辑功能
的客户端应该自动将
对Request-URI的引用重新链接到服务器返回
的
或更多新引用，在可能的情况。这个
响应是可缓存的，除非另有指示
。

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.

新的永久URI应该由响应中的Location字段给出
。
除非请求方法是HEAD，否则
响应的实体应该是b
包含一个短超文本注释，其中包含指向新URI的
超链接。

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).

如果在
中收到301状态代码回应GET
或HEAD以外的请求，则用户代理不能
自动重定向请求
除非可以由
用户确认，因为这可能会改变请求为
的
条件。

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找到

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

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.

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

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).

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

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

为303
响应，在位置字段值上执行GET，而不管原始请求方法的
。状态代码303和307已经为希望明确清楚客户预期会产生
类型反应的服务器添加了
。

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查看其他

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

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.

不同的URI应该由
给出响应中的Location字段。
除非请求方法是HEAD，否则
响应的实体应该是b
包含一个短超文本注释，其中包含指向新URI的
超链接。

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未修改

如果客户端已执行
条件GET请求，并且允许访问
，但该文档未被
修改，服务器应该使用此状态代码回复
。 304
响应绝不能包含
消息体，因此总是
在头字段后面的第一个空行
终止。

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

无时钟原始服务器服从这些
规则，并且代理和客户将
他们自己的日期添加到任何回复
没有一个回复（已经由[RFC 2068]指定的
，
14.19部分），缓存将正常运行。

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

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

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.

如果304响应表明实体
当前没有缓存，然后缓存
必须忽略响应并在没有条件的情况下重复
请求。

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

如果缓存使用收到的304
响应更新缓存条目，
缓存必须更新条目以反映

响应中给出的任何新字段值。

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使用代理

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

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（未使用）

306状态代码用于
之前版本的规范，
不再使用，代码为
reserved。

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临时重定向

请求的资源在不同的情况下临时存在
URI。
由于重定向有时可能会改变
，客户端应该继续使用Request-URI来接收
的未来请求。如果由
Cache-Control或Expires标头字段指示，则此响应只有
可缓存。

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.

临时URI应该由$ b $给出b响应中的位置字段。
除非请求方法是HEAD，否则
响应的实体应该是b
包含一个短的超文本注释，带有
超链接到新的URI，因为
许多pre-HTTP / 1.1用户代理没有
了解307状态。因此，
注释应该包含用户
所需的
信息，以便在新的
URI上重复原始请求。

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.

如果在
中收到307状态代码响应GET
或HEAD以外的请求，则用户代理不能
自动重定向请求
，除非它可以是由
用户确认，因为这可能会更改请求为
的
条件。

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.

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

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

更新&结论：

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

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

推荐答案

我会说 303见其他 302发现：

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

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.

在我看来最符合登录页面。我最初认为 303看到其他也可以。经过一番思考，我会说 302找到更合适，因为找到了所需的资源 ，只有另一页要经过它可以访问。默认情况下，响应不会被缓存，这也很好。

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屋！