HTTP 中的 301、302、303、307、308 响应状态码_开发测试

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

创始人

2024-12-28 09:39:55

0次

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 的补充。

一点额外补充

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

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。