哪个是正确的重定向 HTTP 响应代码？

Question

当网络服务器希望重定向用户的浏览器时，它应该在响应标头中放置哪个状态代码（即“200 OK”）？从我的阅读看来，答案可能是 3XX 代码中的任何一个，但这些代码中的每一个似乎都有不同的描述。只要“位置”在响应标头中，使用哪个甚至重要吗？

Answer 1

这完全取决于您进行重定向的原因。我假设你已经阅读了RFC 2616。

您不想使用 301，除非可能用于页面重命名之类的事情。我不知道有任何 CMS 会自动执行此操作。

具有链接编辑功能的客户端应该自动 将对 Request-URI 的引用重新链接到一个或多个新的 尽可能由服务器返回的引用。

302 非常适合临时 GET-after-GET 并且默认情况下是不可缓存的。它不应该用于 GET-after-POST，因为它实际上意味着 POST-after-POST（在要求用户确认之后）：

注意：RFC 1945 和 RFC 2068 指定不允许客户端 更改重定向请求的方法。然而，大多数 现有的用户代理实现将 302 视为 303 响应，对 Location 字段值执行 GET 的原始请求方法。状态码 303 和 307 有 为希望明确明确哪个服务器添加了 期望客户做出什么样的反应。

303 用于 GET-after-POST。古代浏览器可能不支持它，所以你可能不想在 GET-after-GET 中使用它：

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

307 用于 POST-after-POST（与用户确认后）。它可以用于 GET-after-GET，但在这种情况下，您不妨使用 302/303：

如果收到 307 状态代码以响应其他请求 与 GET 或 HEAD 相比，用户代理不能自动重定向 请求，除非它可以被用户确认，因为这可能 更改发出请求的条件。

至于兼容性，如果有很大比例（1%？）的用户使用不理解 303 或 307 的损坏代理，即使他们声称支持 HTTP/1.1，我也不会感到惊讶。嗯。

Answer 2

为了节省我大量的打字时间 - read this 和 this。

注意 - 并非所有 3xx 代码都进行重定向。但是301、302、303、307的语义是相似的。

Answer 3

根据the Mozilla docs：

重定向响应（形式为 3xx) 表示该资源 请求的客户已搬家，并且 服务器无法为其提供服务 直接地。这些回复中的大多数 包含一些位置信息 告诉在哪里可以找到请求的 资源；用户代理通常然后 无需其他用户即可检索它 相互作用。最常见的回应 这种类型是301 Moved Permanently， 表示给定的 URI 是 no 有效期更长，已移至 另一个地方，还有302 Found 表示资源有 暂时转移到另一个 地点。

注意：对于站长，建议设置301 Moved Permanently重定向时 将页面移动到另一个 URI，在 以网站重组为例。那 允许用户跟随链接仍然 到达资源，它也教 搜索引擎和其他服务 资源的新位置，因此 他们可以将元数据传输到 它。添加也很重要 301 Moved Permanently 响应有足够的缓存头，所以 该信息由 客户并阻止它制作 对原件的不必要要求 获取资源之前的 URI 自己。

有关状态码的更多详细信息，请参阅the W3C。有关不同状态代码如何影响 SEO 的直观表示，请参阅SEO Guide to HTTP Status Codes。

Answer 4

响应代码 302。或者至少，当您调用 sendRedirect() 时，这是 Java 的 HttpServletResponse 发送的。如果这就是 Java 的做法，那可能是有原因的。

301 和 302 在语义上的唯一区别是 301 表示“永久重定向”，而 302 表示“临时重定向”。这是否会转化为实践中的任何差异完全取决于实现协议的客户端。

例如，浏览器可以决定，由于 301 是永久性的，它只会记住它返回的重定向 URL，而不再实际发送对原始 URL 的请求。但这完全取决于浏览器的实现。

也许一个合理的经验法则是，如果您将静态内容移动到新位置，请始终使用 301。但如果您发送重定向以响应对服务器上某些动态代码的请求，那么您应该使用代码 302（或 307）以确保后续请求仍然发送到原始 URL，以防您决定更改/更新您的动态代码以执行不同的操作。