信息 1xx

状态代码的 1xx（信息）类表示临时通信连接状态或请求进度的响应在完成请求的操作并发送最终结果之前回复。1xx 响应由之后的第一个空行终止状态行（表示标题结束的空行部分）。由于 HTTP/1.0 没有定义任何 1xx 状态码，一个服务器不得向 HTTP/1.0 客户端发送 1xx 响应。客户端必须能够解析一个或多个收到的 1xx 响应在最终响应之前，即使客户不期望一个。A用户代理可以忽略意外的 1xx 响应。代理必须转发 1xx 响应，除非代理本身请求1xx 响应的生成。例如，如果代理添加了一个转发请求时的“Expect: 100-continue”字段，则需要不转发相应的 100（继续）响应。

成功 2xx

状态代码的 2xx（成功）类表示客户端的请求被成功接收、理解和接受。

重定向 3xx

状态代码的 3xx（重定向）类表示进一步用户代理需要采取行动以实现要求。如果提供了Location 标头字段，则用户代理可以自动将其请求重定向到 URI由 Location 字段值引用，即使特定状态代码不理解。自动重定向需要完成关注未知安全的方法，因为用户可能不希望重定向不安全的请求。有几种类型的重定向：

1. 指示资源可能在某个位置可用的重定向不同的 URI，由 Location 字段提供，如状态代码 301（永久移动）、302（找到）和 307（临时重定向）。

2. 提供匹配资源选择的重定向，每个能够表示原始请求目标，如300（多项选择）状态代码。

3. 重定向到由 Location 标识的不同资源字段，可以表示对请求的间接响应，如在 303（参见其他）状态代码中。

4. 重定向到先前缓存的结果，如 304 (Not修改）状态码。

注意：在 HTTP/1.0 中，状态码 301（永久移动）和302 (Found) 被定义为第一种类型的重定向。早期的用户代理在是否应用于重定向目标的方法与原始请求或将被重写为 GET。虽然 HTTP最初为 301 和 302 定义了以前的语义（以匹配它在 CERN 的原始实现），并定义了 303（参见其他）为了匹配后者的语义，逐渐流行的做法也收敛于 301 和 302 的后一种语义。这HTTP/1.1 的第一次修订添加了 307（临时重定向）到指示以前的语义而不受发散的影响实践。10 多年后，大多数用户代理仍然使用方法重写 301 和 302；因此，本规范使得当原始请求是 POST 时，该行为是一致的。客户端应该检测并干预循环重定向（即“无限”重定向循环）。注意：本规范的早期版本推荐了一个最多五个重定向（[RFC2068]，第 10.3 节）。内容开发人员需要意识到一些客户可能会实现这样的一个固定的限制。

客户端错误 4xx

4xx（Client Error）状态码类表示客户端好像弄错了。除了在响应 HEAD 请求时，服务器应该发送一个包含解释的表示错误情况，以及它是暂时的还是永久的健康）状况。这些状态代码适用于任何请求方法。用户代理应该向用户显示任何包含的表示。

服务器错误 5xx

5xx（Server Error）状态码类表示服务器意识到它已经犯了错误或无法执行要求的方法。除了在响应 HEAD 请求时，服务器应该发送一个包含解释的表示错误情况，以及它是暂时的还是永久的健康）状况。用户代理应该显示任何包含的表示给用户。这些响应代码适用于任何请求方法。

参考：https://www.rfc-editor.org/rfc/rfc7231#section-6.2.1