当用户未登录并尝试访问需要登录的页面时，重定向到登录页面的正确HTTP状态代码是什么？
10.3.1 300个多项选择
所请求的资源对应于一组表示中的任何一个，每个都有自己的特定位置，并且提供了代理驱动的协商信息（第12节），以便用户（或用户代理）可以选择首选表示并重定向其表示。请求到该位置。
除非它是HEAD请求，否则响应应包含一个实体，其中包含资源特征和位置的列表，用户或用户代理可以从中选择最合适的一个。实体格式由“内容类型”标头字段中提供的媒体类型指定。取决于格式和功能
用户代理，可以自动执行最合适的选择。但是，该规范没有为这种自动选择定义任何标准。
如果服务器具有首选的表示形式，则应在“位置”字段中包含该表示形式的特定URI；用户代理可以使用“位置”字段值进行自动重定向。除非另有说明，否则此响应是可缓存的。
10.3.2 301永久移动
所请求的资源已被分配了一个新的永久URI，对该资源的任何将来引用都应使用返回的URI之一。具有链接编辑功能的客户端应在可能的情况下自动将对Request-URI的引用重新链接到服务器返回的一个或多个新引用。除非另有说明，否则此响应是可缓存的。
新的永久URI应该由响应中的Location字段给出。除非请求方法是HEAD，否则响应的实体应该包含简短的超文本注释，并带有指向新URI的超链接。
如果响应GET或HEAD以外的请求而收到301状态码，则用户代理不得自动重定向请求，除非用户可以确认，因为这可能会更改发出请求的条件。
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标头字段指示时，此响应才可缓存。
临时URI应该由响应中的Location字段给出。除非请求方法是HEAD，否则响应的实体应该包含简短的超文本注释，并带有指向新URI的超链接。
如果响应GET或HEAD以外的请求而收到302状态码，则用户代理不得自动重定向请求，除非用户可以确认，因为这可能会更改发出请求的条件。
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响应，无论原始请求方法如何，都对Location字段值执行GET。已为希望明确弄清客户端期望哪种反应的服务器添加了状态代码303和307。
10.3.4 303查看其他
可以在不同的URI下找到对请求的响应，并且应该使用该资源上的GET方法来检索该请求。存在此方法主要是为了允许POST激活的脚本的输出将用户代理重定向到选定的资源。新URI不能替代原始请求的资源。303响应一定不能被缓存，但是对第二个（重定向的）请求的响应可能是可缓存的。
响应中的Location字段应给出不同的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来处理以后的请求。仅当由Cache-Control或Expires标头字段指示时，此响应才可缓存。
临时URI应该由响应中的Location字段给出。除非请求方法是HEAD，否则响应的实体应包含简短的超文本注释，并带有指向新URI的超链接，因为许多HTTP / 1.1之前的用户代理不了解307状态。因此，注释应该包含用户在新URI上重复原始请求所必需的信息。
如果响应GET或HEAD以外的请求而接收到307状态码，则用户代理不得自动重定向请求，除非用户可以确认，因为这可能会更改发出请求的条件。
我使用的是302，现在，直到我找到了正确的答案。
更新和结论：
HTTP 302更好，因为它与客户端/浏览器具有最佳兼容性。