HTTP五大类标准状态码一网打尽

【概述】

状态码是服务器在响应客户端向请求时发出的结果码。

状态码的第一个数字指定了五个标准的响应类别中的一个。

所展示的消息短语是经典通用的，人类可读的。

互联网号码分配机构(IANA)维护着HTTP状态码的官方注册表。

所有HTTP响应的状态码都被分为五个分类。

状态码的第一位数字定义了响应的类别，而后两位数字没有任何分类或归类的作用。

五个类别:

l  1xx --------------------信息性响应--收到请求，继续处理中

l  2xx成功-------------成功地收到，并处理了请求；

l  3xx重新定向-------需要采取进一步行动才能完成请求

l  4xx客户端错误----请求包含错误的语法或无法满足的请求

l  5xx服务器错误----服务器未能完成一个有效的请求。

【1xx 信息性响应】

信息性响应表示已收到并理解请求。

它是在请求处理过程中临时发出的。

它提醒客户机等待最终的响应。

该消息仅由状态行和可选的头字段组成，并以空行结束。

由于HTTP/1.0标准没有定义任何1xx状态码，所以服务器不能向符合HTTP/1.0标准的客户端发送1xx响应。

100 继续

如果服务器已经收到了请求头，客户端应该继续发送请求正文（如需要发送正文的请求的话，例如POST请求）。

在请求因不合适的标题而被拒绝后，再向服务器请求正文是没有意义的。

为了让服务器先检查请求头，客户端必须在发送body之前，在初始请求中发送Expect: 100-continue作为请求头，并在响应中收到一个100 Continue状态码。

如果客户端收到一个错误代码，如403（Forbidden）或405（Method Not Allowed），那么它不应该再发送请求正文。

响应417 Expectation Failed表示请求应该在没有Expect头的情况下重复请求，因为它表示服务器不支持Expect头（例如，HTTP/1.0服务器就是这种情况）。

101切换协议

请求者要求服务器切换协议，服务器也同意切换协议。

102处理（WebDAV，RFC 2518）

一个WebDAV请求可能包含许多涉及文件操作的子请求，需要很长时间才能完成请求。这个代码表示服务器已经收到并正在处理请求，但还没有响应，这可以防止客户端超时从而假设请求丢失。

103早期提示(RFC 8297)

用于在最终的HTTP报文之前返回一些响应头。

【2xx成功】

这类状态码表示客户的请求已被接收、理解和处理。

200 OK

成功的HTTP请求的标准响应。

实际的响应将取决于所使用的请求方法。在GET请求中，响应将包含一个与请求资源相对应的实体。

在POST请求中，响应将包含一个描述或包含操作结果的实体。

201 已创建

该请求已被处理，从而创建了新的资源。

202 已接受

请求已被接受并处理，但处理工作尚未完成。

该请求最终可能会被处理完成，也可能不会，这取决于处理时是否被驳回。

203非授权信息（自HTTP/1.1以来）

服务器是一个转换代理（如Web加速器），它收到了200 OK，但返回的是原始响应的修改版本。

204 无内容

服务器成功处理了该请求，没有返回任何内容。

205内容重置

服务器成功处理了请求，但没有返回任何内容。与204响应不同的是，这个响应要求请求者重置文档视图。

206部分内容（RFC 7233）

由于客户端发送的范围头，服务器只传递了部分资源（字节服务）。

范围报头被HTTP客户端用来启用中断的下载，或者将一个下载分成多个同步流。

207 多状态（RFC 4918）。

后面的消息体默认是一个XML消息，可以包含多个独立的响应代码，这取决于有多少个子请求。

208 已报告(RFC 5842)

DAV 绑定的成员已经在（多状态）响应的前一部分中列举过了，现在不再包含。

226 已使用的 IM（RFC 3229）

服务器已经完成了对资源的请求，响应是对当前的一个或多个实例操作结果的表示。

【3xx重定向】

这类状态码表示客户端必须采取额外的行动来完成请求。

这些状态码中的很多都用于URL重定向。

只有在第二请求中使用的方法是GET或HEAD的情况下，用户代理才可以在没有用户交互的情况下执行附加动作。

用户代理可以自动重定向一个请求。

用户代理应该检测并干预以防止周期性的重定向。

300 多项选择

表示客户端可以从中选择多个资源选项（通过代理驱动的内容协商）。例如，这个代码可以用来显示多个视频格式选项，列出具有不同文件扩展名的文件，或者列出多个选项。

301永久移动

当前和今后的所有请求都指向给定的URI。

302发现(原为"临时移动")

告诉客户端查看另一个URL。

302已经被303和307取代。

这是一个与标准相矛盾的行业实践的例子。

HTTP/1.0规范(RFC 1945)要求客户端执行临时重定向，但流行的浏览器用303的See Other功能实现了302。

因此，HTTP/1.1增加了状态码303和307来区分这两种行为。

然而，一些Web应用和框架把302的状态码当做303来使用。

303 见其他（自HTTP/1.1以来）

使用GET方法可以在另一个URI下找到对请求的响应。

当收到对POST（或PUT/DELETE）的响应时，客户端应假定服务器已收到数据，并应向给定的URI发出新的GET请求。

304 未修改(RFC 7232)

表示该资源自标题请求If-Modified-Since或If-Non-Match所指定的版本后没有被修改。

在这种情况下，不需要重新发送资源，因为客户端仍然有一个以前下载的副本。

305 使用代理(自HTTP/1.1以来)

所请求的资源只能通过代理使用，代理的地址在响应中提供。出于安全考虑，许多HTTP客户端（如Mozilla Firefox和Internet Explorer）不遵守这个状态代码。

306 交换机代理

不再使用。原意为 "以后的请求应使用指定的代理"。

307 临时重定向（自HTTP/1.1以来）

在这种情况下，请求应该用另一个URI重发。

但是，未来的请求仍然应该使用原来的URI。

与302在历史上的实现方式不同，在重发原始请求时不允许改变请求方法。

例如，一个POST请求应该使用另一个POST请求来重发。

308永久重定向(RFC 7538)

当前请求和以后的所有请求都应该使用另一个URI。

307和308与302和301的行为并行，但不允许HTTP方法改变。

因此，提交一个表单到一个永久重定向的资源，可能会持续下去。

【4xx 客户端错误】

这类状态代码用于由客户端引起的错误情况。

除了响应HEAD请求时，服务器应该包含一个错误情况的解释实体，以及说明是暂时的还是永久的。

这些状态代码适用于任何请求方式。

用户代理应该向用户显示所有包含的实体。

400 不良请求

由于明显的客户机错误（如：请求语法错误、过大、无效的请求消息或欺骗性的请求路由等），服务器无法处理请求。

401未经授权(RFC 7235)

类似于403 Forbidden，但专门用于需要认证但已经失败或尚未提供认证的情况下使用。

响应必须包括一个WWW-Authenticate头字段，其中包含一个适用于请求资源的挑战。

401在语义上意味着 "未授权"，用户没有目标资源的有效认证凭证。

注意：当一个IP地址被禁止访问网站时（通常是网站域名），有些网站会错误地发出HTTP 401。

402 需要支付

留待将来使用。

最初的意图是，该代码会被作为某种形式的数字现金或小额支付计划的一部分，例如GNU Taler提出的。

但到目前还没有发生，而且这该代码并没有被广泛使用。

Google Developers API在某个特定的开发者超过了每天的请求限制时使用了这个状态。

Sipgate在账户没有足够的资金调用时使用了这个代码。

Shopify在商店没有支付他们的费用而被暂时禁用时使用了这个代码。

Stripe在屏蔽欺诈性支付时，使用了这个代码。

403 禁止访问

该请求包含有效的数据，而且服务器也能理解，但服务器拒绝处理。

这是由于用户没有必要的权限，或者需要某种类型的账户，或者试图进行禁止的操作（例如，在只允许一个唯一记录的情况下创建一个重复记录）。

如果请求通过WWW-Authenticate头字段提供了验证，但服务器没有接受该验证，则通常也会使用此代码。

该请求不应重复进行。

404 未找到

所请求的资源无法找到，但将来可能会有， 因此客户端继续请求是允许的。

405 方法不允许

不支持被请求资源的请求方法，例如，在要求通过POST显示数据的表单上使用GET请求，或者在只读资源上使用PUT请求。

406 不可接受

所请求的资源只能够根据请求中发送的Accept headers生成无效的内容。

407 需要代理认证（RFC 7235）

客户端必须先通过代理进行身份验证。

408 请求超时

服务器超时等待请求。

根据HTTP规范的规定，客户端没有在服务器等待的时间内发出请求。

客户端可在以后的任何时间不加修改地重复请求。

409 冲突

表示由于资源的当前状态有冲突，比如多个同时更新数据之间的编辑冲突，导致请求无法处理。

410 消失

表示所请求的资源已不再可用。

当资源被故意删除并清除资源时，应使用该代码。

客户端在收到410状态码后，今后不应再请求该资源。

客户端（如搜索引擎）应该将该资源从其索引中删除。

大多数用例不要求客户端和搜索引擎清除该资源，这时可以使用 "404 未发现"代替。

411长度需指定

所请求的资源所要求的长度未指定。

412先决条件失败(RFC 7232)

服务器不符合请求者在请求头字段上提出的一个前提条件。

413 有效载荷过大(RFC 7231)

发出了大于服务器能够处理的请求。以前称为 "请求实体过大"。

414 URI Too Long (RFC 7231)

提供的URI太长，服务器无法处理。

通常是由于GET请求的查询字符串中编码的数据太多， 在这种情况下，应该转换为POST请求。

以前叫 "Request-URI Too Long"。

415 不支持的媒体类型(RFC 7231)

请求实体的媒体类型在服务器上不支持。

416 范围不满足(RFC 7233)

客户端请求了文件的一部分（字节服务），但服务器无法提供这一部分。例如，如果客户端要求的文件的一部分超出了文件的末尾。

之前称为 "Requested Range Not Satisfiable"。

417 期望落空

服务器无法满足Expect request-header字段的要求。

418 我是茶壶（RFC 2324，RFC 7168）。

这个代码在1998年被定义为传统的IETF愚人节玩笑之一，在RFC 2324《超文本咖啡壶控制协议》（Hyper Text Coffee Pot Control Protocol）中，预计不会被实际的HTTP服务器实现。

RFC规定这个代码应该由请求冲泡咖啡的茶壶返回。

这个HTTP状态在一些网站中被用作复活节彩蛋，比如Google.com的I'm a teapot easter egg。

421错误定向请求（RFC 7540）

该请求是指向无法产生响应的服务器（例如连接重用）。

422 不可处理的实体（RFC 4918）

该请求的形式很好，但由于语义错误而无法得到实施。

423锁定(RFC 4918)

被访问的资源被锁定了。

424 失败的依赖性(RFC 4918)

该请求失败是因为它依赖于另一个请求，而那个请求失败了（例如，PROPPATCH）。

425过早（RFC 8470）

表示服务器不愿意冒险处理可能被重播的请求。

426 需要升级

客户端应切换到不同的协议，如TLS/1.0等，在升级头字段中给出。

428 所需的先决条件（RFC 6585）。

源服务器指定进行的请求是有条件的。

意在防止 "丢失更新"的问题，即客户端GET到资源的状态，修改它，然后把它PUT回服务器，同时第三方修改了服务器上的状态，导致冲突。

429 太多的请求（RFC 6585）。

用户在一定的时间内发送了太多的请求。专用于限速方案。

431 请求标题字段过大 (RFC 6585)

服务器不愿意处理请求，因为单个头字段或所有的头字段合起来太大。

451 由于法律原因不可用(RFC 7725)

服务器运营商收到了一个合法的要求，拒绝访问一个资源或包括所请求的资源的资源集，选择代码451是为了参考小说《华氏451》（见RFC中的Acknowledgements）。

【5xx服务器错误】

服务器未能满足请求。

以数字 "5 "开头的响应状态代码表示服务器意识到自己遇到了错误或无法执行请求的情况。

除了响应HEAD请求之外，对于其他请求，服务器还应该包含一个错误情况解释的实体，并说明是临时性的还是永久性的。

同样，用户代理也应该向用户显示任何包含的实体。

这些响应代码适用于任何请求方式。

500 内部服务器错误

通用的错误信息，当遇到意外情况而没有更具体的信息适合时给出的通用错误信息。

501 未执行

服务器要么不识别该请求方法，要么缺乏实现该请求的能力。通常这意味着未来的可用性（例如，Web服务API的一个新功能）。

502不良通道

服务器作为网关或代理，收到了来自上游服务器的无效响应。

503 服务不可用

服务器无法处理该请求（如因为超载或停机维护）。一般来说，这是一种临时状态。

504个网关超时

该服务器作为网关或代理，没有及时收到上游服务器的响应。

505 HTTP版本不支持

服务器不支持请求中使用的HTTP协议版本。

506变化协商(RFC 2295)

透明的内容协商请求的结果为循环引用。

507 存储不足（RFC 4918）。

服务器无法存储完成请求所需的表示方式。

508环路检测（RFC 5842）。

服务器在处理请求时检测到一个无限循环。

510未扩展（RFC 2774）

服务器需要对请求进行进一步的扩展才能满足请求。

511 网络认证要求(RFC 6585)

客户端需要进行身份验证才能获得网络访问。目的是通过拦截用于控制网络访问的代理（例如，"圈养门户"，要求在通过Wi-Fi热点授予完全的互联网访问权之前，必须同意服务条款）。

【小结】

本文对HTTP请求所有可能涉及到的五大类状态码进行了学习和探讨， 希望对大家有用。

HTTP

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。