HTTP 中的 301、302、303、307、308 响应状态码

对 HTTP 有所了解的人，大概都清楚 3 开头的响应状态码都表示重定向的响应。但是具体细节究竟是什么，看似类似的效果，在本质上究竟有什么不同？

如果你不能说清楚标题中五个状态码的具体差别，那么这篇文章应该会帮到你。

首先先来看一下，HTTP 中这五个响应状态码的名字：

根据 RFC 7231

• 301 Moved Permanently
• 302 Found
• 303 See Other
• 307 Temporary Redirect

根据 RFC 7538

• 308 Permanent Redirect

从名字可以看出来，301、308 是永久重定向，剩下的三个不一定能从名字看出来作用是什么，所以干脆记住它们都是临时重定向就好了。

302、303 与 307

我们从临时重定向开始，先放上它们 302、303、307 最新的定义，之后再去解释这些重定向之间的差别。（这些定义并不是对 RFC 文档的逐字翻译，为了解释清楚我会省略或转述一些信息。）

302 Found 的定义

302 状态码表示目标资源临时移动到了另一个 URI 上。由于重定向是临时发生的，所以客户端在之后的请求中还应该使用原本的 URI。

服务器会在响应 Header 的 Location 字段中放上这个不同的 URI。浏览器可以使用 Location 中的 URI 进行自动重定向。

注意：由于历史原因，用户代理可能会在重定向后的请求中把 POST 方法改为 GET 方法。如果不想这样，应该使用 307（Temporary Redirect） 状态码。（之后我们会详细叙述历史原因）

303 See Other 的定义

303 状态码表示服务器要将浏览器重定向到另一个资源，这个资源的 URI 会被写在响应 Header 的 Location 字段。从语义上讲，重定向到的资源并不是你所请求的资源，而是对你所请求资源的一些描述。

303 常用于将 POST 请求重定向到 GET 请求，比如你上传了一份个人信息，服务器发回一个 303 响应，将你导向一个“上传成功”页面。

不管原请求是什么方法，重定向请求的方法都是 GET（或 HEAD，不常用）。

到这里你可能发现，303 和 302 的作用很类似，除去语义差别，似乎是 302 包含了 303 的情况。确实，这是由历史原因导致的。我们先来看一下 307 的效果。

307 Temporary Redirect 的定义

307 的定义实际上和 302 是一致的，唯一的区别在于，307 状态码不允许浏览器将原本为 POST 的请求重定向到 GET 请求上。

302 与 303、307 的关系

区别

在这里总结一下，从实际效果看：302 允许各种各样的重定向，一般情况下都会实现为到 GET 的重定向，但是不能确保 POST 会重定向为 POST；而 303 只允许任意请求到 GET 的重定向；307 和 302 一样，除了不允许 POST 到 GET 的重定向。

简要历史原因

那为什么有了 307 和 303 还需要 302呢？把总结放在最前面。302 在最初的定义中，内容和现在的 307 是一样的，不允许重定向方法的改写（从 POST 到 GET，由于 GET 不应该有 body，实际上 body 也被改了）。但是早期浏览器在实现的时候有的实现成 303 的效果，有的实现成 307 的效果。于是在之后的标准，302 在某些浏览器中错误的实现被写进规范，成为 303，而 302 原本的效果被复制了到了 307。在最近的一次标准修订中，302 标准被修改成不再强制需要维持原请求的方法。所以就产生了现在的 302、303 和 307

详细的历史原因（可以跳过）

在 1995 年 6 月的 RFC 1945 HTTP 1.0 标准，302 被称为 Moved Temporarily，而不是现在的 Found。标准中提到，有些浏览器收到了 302 状态码，在自动重定向时候会错误的把 POST 方法转为 GET 方法：

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

这个错误在 1997 年 1 月的 RFC 2068 HTTP 1.1 标准提出时，仍然没有被修正。此时标准中依然只有 302 Moved Temporarily。

但是谁知道两年多过去了，浏览器厂商们懒得改。那既然厂商不改，就标准改吧。

在 1999 年 6 月的 RFC 2616 中，增加了 303 与 307，与此同时 302 被更名为 Found。标准中提到：

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.

简单来说，就是之前的标准都写了不允许重定向的时候改写方法，但是大多数浏览器还把 302 当成 303 那样处理。那干脆把两种不同的行为区分成 303 和 307。

302 标准就被那么放着了。

最终，2014 年 6 月的 RFC 7231 中，修改了对 302 的定义：

The user agent MAY use the Location field value for automatic redirection.

在之前的标准中，这句话中的 MAY 都是 MUST NOT。标准妥协了，既然现在大多数浏览器都支持了 307 和 303，那 302 的标准也就改了吧。

这就是 303、307 与 302 的关系。

301 与 308

有了之前的对 302、303、307 的理解，对 301 和 308 的理解就简单多了。

301 Moved Permanently 的定义

301 状态码表明目标资源被永久的移动到了一个新的 URI，任何未来对这个资源的引用都应该使用新的 URI。

308 Permanent Redirect 的定义

308 的定义实际上和 301 是一致的，唯一的区别在于，308 状态码不允许浏览器将原本为 POST 的请求重定向到 GET 请求上。

301 与 308 的历史

和 302 一样，301 在浏览器中的实现和标准是不同的，这个时间一直延续到 2014 年的 RFC 7231，301 定义中的 Note 还是提到了这个问题。直到 2015 年 4 月，RFC 7538 提出了 308 的标准，类似 307 Temporary Redirect 之于 302 Found 的存在，308 成为了 301 的补充。

一点额外补充

临时重定向和永久重定向对搜索引擎会产生不同的效果。

到这里，301、302、303、307、308 的关系大致就能理清了。希望这篇文章能让你更好的理解这几个 HTTP 响应状态码。

如果你对如何使用这些状态码还有疑问，可以查看

这个回答里的插图会对你有一些帮助。