关于HTTP响应码为302 303 307 的两点疑问

Question

https://www.cnblogs.com/cswuy...
参考了这篇关于302 303 307 的分析，我理解的如下：

在 http1.0 时期，

• 文档规定：第一次请求得到 302 响应，浏览器询问用户是否以同样的 Method 向新 URL 发送请求
• 在浏览器实现上，为遵循幂等原则，若用户第一次为 POST 请求，浏览器询问用户是否向新 URL 发送请求，并强制使用 GET发送第二个请求（与文档规定有所差异）

http1.1 时期

为了弥补 http1.0 时期文档中 302 和浏览器实现上 302 的偏差，补充了303 307 状态码

• 303：迎合幂等原则，使用上边第二点的处理流程。当第一次请求响应码为 POST，询问用户，第二次以 GET 向新 URL 发送请求。
• 307：为原文档规定的 302 处理方法。第一次第二次请求的 Method 不能有变。

我的问题有两个

1. 303 307 是对 302 的补充是否正确？
2. 上边描述中浏览器的处理流程是否正确？

如有错误，请大佬们指正，不胜感激！

Answer 1

基本是对的。

301、302 在 HTTP 协议里确实规定了要以原谓词重新发起新的重定向请求，但实际的所有主流库都实现成不管第一次是啥谓词、重定向后都变成了 GET。之所以说是 “主流库”，是因为不仅仅是浏览器，也包含 HTTP 的编程库（如 Java 中的 HttpClient 类）。为了不造成兼容性问题，也就这么着了，在错误的道路上继续大踏步前进。

后来为了解决这一问题，又先后提出了 302 的进化版 303/307、以及 301 的进化版 308 等几个新状态码。

不过要注意的是，这几个新状态码并不是一开始就随着 HTTP/1.1 一起被提出的，而是在 2014 年才制订出的 RFC-7231、RFC-7538 里才提出，作为 HTTP/1.1 协议的补充。

这时候距离 HTTP/1.1 诞生都已经过去十几年了，某些 Web 应用出现的比这俩 RFC 规范还要早，已经把这些状态码用作私有的定义了，所以实际上，又出现了当年 302 的老问题。

P.S. 一开始 301/302 为啥实现和设计有出入，究竟是哪个浏览器或编程库搞错了，关于这一点我没找到相关的信息。