HTTP Code含义

怎么可能-怎么可能

于 2023-02-16 16:35:10 发布

阅读量1.5k

点赞数

分类专栏： java基础配置文章标签： html Powered by 金山文档

本文链接：https://blog.csdn.net/u014259503/article/details/129064057

版权

配置同时被 2 个专栏收录

10 篇文章 0 订阅

订阅专栏

java基础

3 篇文章 0 订阅

订阅专栏

HTTP Code	描述	详细
100	继续	100（继续）状态代码表示一个已收到请求，尚未被拒绝服务器。服务器打算在请求已完全收到并已采取行动。当请求包含 Expect 标头字段时100-continue expectation，100响应表示服务器希望接收请求有效负载主体。客户端应该继续发送请求并且丢弃 100 响应。如果请求不包含包含100-continue 期望，客户可以简单地丢弃这个临时回复。
101	交换协议	101（切换协议）状态代码表示服务器理解并愿意遵守客户的要求，通过升级标头字段（[RFC7230] 的第 6.7 节），用于更改此连接上使用的应用程序协议。服务器必须在响应中生成一个升级头字段，指示空后立即切换到哪个协议终止 101 响应的行。假设服务器只会同意切换协议在有利的时候这样做。例如，切换到较新的HTTP 版本可能优于旧版本，并且切换到实时同步协议可能是有利的在交付使用此类功能的资源时。
200	好的	200（OK）状态码表示请求成功。200 响应中发送的负载取决于请求方法。对于本规范定义的方法，其预期含义payload 可以概括为：GET 目标资源的表示；HEAD 与 GET 相同的表示，但没有表示数据;发布状态的表示或从中获得的结果，那个行动;PUT、DELETE 表示动作的状态；OPTIONS 通信选项的表示；TRACE 表示最后收到的请求消息服务器。除了对 CONNECT 的响应之外，200 响应始终具有有效负载，尽管原始服务器可以生成零长度的有效负载主体。如果不需要负载，源服务器应该发送 204（否内容）代替。对于 CONNECT，不允许任何有效载荷，因为成功的结果是一条隧道，它在 200 之后立即开始响应头部分。默认情况下，200 响应是可缓存的；即，除非另有说明由方法定义或显式缓存控制指示（请参阅[RFC7234] 的第 4.2.2 节）。
201	已创建	201（Created）状态码表示请求已经完成实现并导致一个或多个新资源被创建。标识了请求创建的主要资源通过响应中的 Location 标头字段，或者，如果没有 Location字段由有效请求 URI 接收。201 响应负载通常描述并链接到已创建资源。有关含义的讨论，请参见第 7.2 节验证器标头字段的用途，例如 ETag 和Last-Modified，在 201 响应中。
202	已接受
203	非权威信息
204	没有内容
205	重置内容
206	部分内容
300	多项选择
301	永久移动
302	发现
303	查看其他
304	未修改
305	使用代理
307	临时重定向
400	错误请求
401	未经授权
402	需要付款
403	禁止
404	未找到
405	方法不允许
406	不可接受
407	需要代理身份验证
408	请求超时
409	冲突
410	走了
411	要求长度
412	前提条件失败
413	负载过大
414	URI 太长
415	不支持的媒体类型
416	范围不满足
417	期望失败
426	需要升级
500	内部服务器错误
501	未实施
502	坏网关
503	服务不可用
504	网关超时
505	不支持 HTTP 版本

信息 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 节）。内容开发人员需要意识到一些客户可能会实现这样的一个固定的限制。