此类状态代码表示临时响应，仅由状态行和可选标题组成，并以空行结束。此类状态代码没有必需的标题。由于 HTTP/1.0 没有定义任何 1xx 状态代码，除非在实验条件下，否则服务器不得向 HTTP/1.0 客户端发送 1xx 响应。

在常规响应之前，客户端必须准备好接受一个或多个 1xx 状态响应，即使客户端不期望收到 100(继续)状态消息。用户代理可能会忽略意外的 1xx 状态响应。

除非代理与其客户端之间的连接已经关闭，或者除非代理本身请求生成 1xx 响应，否则代理必须转发 1xx 响应。(例如，如果代理在转发请求时添加了“Expect: 100-continue”字段，则它不需要转发相应的 100 (Continue)响应。)

客户端应该继续其请求。这个临时响应用于通知客户端请求的初始部分已经被接收，并且还没有被服务器拒绝。客户端应该继续发送请求的剩余部分，如果请求已经完成，则忽略该响应。请求完成后，服务器必须发送最终响应。

服务器理解并愿意通过升级消息头字段遵从客户端的请求，更改此连接上使用的应用程序协议。服务器将在终止 101 响应的空行之后立即将协议切换到由响应的升级头字段定义的协议。

只有在有利的情况下，才应该切换协议。例如，切换到较新版本的 HTTP 比旧版本更有优势，而切换到实时同步协议在交付使用此类功能的资源时可能更有优势。

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

请求已成功。响应返回的信息取决于请求中使用的方法，例如:

在响应中发送与所请求的资源相对应的实体；

对应于所请求的资源的实体头字段在响应中被发送，而没有任何消息体；

发布描述或包含操作结果的实体；

跟踪包含终端服务器接收到的请求消息的实体。

请求已完成，并导致创建新资源。新创建的资源可以由响应实体中返回的 URI 引用，资源的最具体 URI 由位置头字段给出。响应应包括一个实体，该实体包含资源特征和位置的列表，用户或用户代理可以从中选择最合适的一个。实体格式由内容类型标题字段中给出的媒体类型指定。源服务器必须在返回 201 状态代码之前创建资源。如果操作不能立即执行，服务器应该用 202(接受)响应来代替。

201 响应可能包含一个 ETag 响应头字段，指示刚刚创建的请求变体的实体标签的当前值。

请求已被接受进行处理，但处理尚未完成。请求最终可能会被执行，也可能不会被执行，因为在实际执行处理时可能会被禁止。没有从这样的异步操作中重新发送状态代码的工具。

202 的回应是故意不承诺。它的目的是允许服务器接受对其他进程的请求(可能是一个面向批处理的进程，每天只运行一次)，而不需要用户代理与服务器的连接持续到进程完成。与这个响应一起返回的实体应该包括一个请求当前状态的指示，以及一个指向状态监视器的指针，或者对用户何时可以期望请求被满足的一些估计。

实体头中返回的元信息不是从源服务器获得的最终集合，而是从本地或第三方副本收集的。所呈现的集合可以是原始版本的子集或超集。例如，包含关于资源的本地注释信息可能会产生源服务器已知的元信息的超集。不需要使用此响应代码，仅当响应为 200(正常)时才适用。

服务器已经完成了请求，但是不需要返回实体主体，并且可能想要返回更新的元信息。该响应可以包括实体标题形式的新的或更新的元信息，如果存在的话，该元信息应该与所请求的变体相关联。

如果客户端是用户代理，它不应该从导致发送请求的视图中更改其文档视图。尽管任何新的或更新的元信息都应该应用于当前处于用户代理活动视图中的文档，但此响应主要是为了允许输入操作，而不会导致用户代理的活动文档视图发生变化。

204 响应不得包含消息正文，因此总是由报头字段后的第一个空行终止。

服务器已完成请求，用户代理应重置导致发送请求的文档视图。该响应主要用于允许通过用户输入进行动作输入，随后清除给出输入的表单，以便用户可以容易地启动另一个输入动作。回应不得包含实体。

服务器已经完成了对资源的部分 GET 请求。请求必须包含一个范围标题字段，指示所需的范围，并且可能包含一个 If-Range 标题字段，以使请求有条件。

如果 206 响应是使用强缓存验证器的 If-Range 请求的结果，则该响应不应包含其他实体头。如果响应是使用弱验证器的 If-Range 请求的结果，则响应不得包含其他实体头；这防止了缓存的实体体和更新的头之间的不一致。否则，响应必须包括所有的实体头，这些实体头将与对同一请求的 200 (OK)响应一起返回。

如果 ETag 或上次修改的标头不完全匹配，缓存不得将 206 响应与其他先前缓存的内容组合在一起。

不支持范围和内容范围标头的缓存不得缓存 206(部分)响应。

这类状态代码表明用户代理需要采取进一步的行动来满足请求。当且仅当第二个请求中使用的方法是 GET 或 HEAD 时，所需的操作可以由用户代理执行，而无需与用户交互。客户端应该检测无限重定向循环，因为这样的循环会为每次重定向生成网络流量。

所请求的资源对应于一组表示中的任何一个，每个表示具有其自己的特定位置，并且代理驱动的协商信息(部分 12)被提供，使得用户(或用户代理)可以选择优选的表示并且将其请求重定向到该位置。

除非是 HEAD 请求，否则响应应包括一个实体，该实体包含一个资源特征和位置列表，用户或用户代理可以从中选择最合适的一个。实体格式由内容类型标题字段中给出的媒体类型指定。根据用户代理的格式和能力，可以自动选择最合适的选项。然而，本规范没有为这种自动选择定义任何标准。

如果服务器有首选的表示方式，则应在“位置”字段中包含该表示方式的具体 URI；用户代理可以使用位置字段值进行自动重定向。除非另有说明，否则此响应是可缓存的。

请求的资源已被分配了一个新的永久 URI，任何对该资源的未来引用都应该使用返回的 URIs 之一。具有链接编辑功能的客户端应该在可能的情况下，自动将对请求 URI 的引用重新链接到服务器返回的一个或多个新引用。除非另有说明，否则此响应是可缓存的。

新的永久 URI 应由响应中的位置字段给出。除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，并带有指向新 URI 的超链接。

如果收到的 301 状态代码是对 GET 或 HEAD 以外的请求的响应，用户代理不得自动重定向该请求，除非用户能够确认，因为这可能会改变发出请求的条件。

请求的资源暂时驻留在不同的 URI 下。由于重定向有时可能会被更改，客户端应该继续使用请求-URI 来处理未来的请求。仅当缓存控制或过期标头字段指示时，此响应才是可缓存的。

临时 URI 应由响应中的位置字段给出。除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，并带有指向新 URI 的超链接。

如果 302 状态代码是响应 GET 或 HEAD 之外的请求而接收的，用户代理不得自动重定向该请求，除非它能被用户确认，因为这可能会改变发出该请求的条件。

对请求的响应可以在不同的 URI 下找到，应该使用该资源上的 GET 方法来检索。该方法的存在主要是为了允许 POST 激活脚本的输出将用户代理重定向到选定的资源。新 URI 不能替代最初请求的资源。不能缓存 303 响应，但是对第二个(重定向的)请求的响应可能是可缓存的。

不同的 URI 应由响应中的位置字段给出。除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，并带有指向新 URI 的超链接。

如果客户端执行了有条件的 GET 请求，并且允许访问，但是文档没有被修改，那么服务器应该用这个状态代码来响应。304 响应不得包含消息正文，因此总是由报头字段后的第一个空行终止。

如果无时钟的源服务器遵守这些规则，并且代理和客户端将它们自己的日期添加到任何没有日期的响应中，缓存将正确运行。

如果条件 GET 使用了强缓存验证器，那么响应就不应该包含其他实体头。否则(即条件 GET 使用弱验证器)，响应不能包含其他实体头；这防止了缓存的实体体和更新的头之间的不一致。

如果 304 响应指示当前未缓存的实体，则缓存必须忽略该响应，并在没有条件的情况下重复请求。

如果高速缓存使用接收到的 304 响应来更新高速缓存条目，则高速缓存必须更新条目以反映响应中给出的任何新字段值。

必须通过“位置”字段给出的代理来访问请求的资源。位置字段给出代理的 URI。预期收件人将通过代理重复此单个请求。305 响应必须仅由原始服务器生成。

306 状态代码在以前版本的规范中使用过，现在不再使用，该代码已被保留。

请求的资源暂时驻留在不同的 URI 下。由于重定向有时可能会改变，客户端应该继续使用请求-URI 来处理未来的请求。仅当缓存控制或过期标头字段指示时，此响应才是可缓存的。

临时 URI 应由响应中的位置字段给出。除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，带有指向新 URI 的超链接，因为许多 HTTP/1.1 之前的用户代理不理解 307 状态。因此，注释应包含用户在新 URI 上重复原始请求所需的信息。

如果收到的 307 状态代码是对 GET 或 HEAD 以外的请求的响应，用户代理不得自动重定向该请求，除非用户能够确认，因为这可能会改变发出请求的条件。

4xx 类的状态代码旨在用于客户端似乎出错的情况。除了在响应 HEAD 请求时，服务器应该包括一个实体，该实体包含错误情况的解释，以及它是暂时的还是永久的情况。这些状态代码适用于任何请求方法。用户代理应向用户显示任何包含的实体。

如果客户端正在发送数据，使用 TCP 的服务器实现应该小心确保客户端在服务器关闭输入连接之前确认收到包含响应的数据包。如果客户端在关闭后继续向服务器发送数据，服务器的 TCP 堆栈将向客户端发送重置数据包，这可能会在客户端的未确认输入缓冲区被 HTTP 应用程序读取和解释之前将其清除。

由于语法不正确，服务器无法理解该请求。未经修改，客户不得重复请求。

该请求需要用户身份验证。响应必须包括一个包含适用于所请求资源的质询的万维网认证报头字段。客户端可以用合适的授权头字段重复请求。如果请求已经包括授权凭证，则 401 响应指示那些凭证的授权已经被拒绝。如果 401 响应包含与先前响应相同的询问，并且用户代理已经尝试认证至少一次，则应该向用户呈现在响应中给出的实体，因为该实体可能包括相关的诊断信息。HTTP 访问身份验证在“HTTP 身份验证:基本和摘要访问身份验证”中进行了解释。

此代码保留供将来使用。

服务器理解这个请求，但是拒绝满足它。授权没有帮助，请求不应重复。如果请求方法不是 HEAD，并且服务器希望公开请求未被满足的原因，它应该在实体中描述拒绝的原因。如果服务器不希望使该信息对客户端可用，则可以使用状态代码 404(未找到)。

服务器没有找到任何与请求 URI 匹配的内容。没有迹象表明这种情况是暂时的还是永久的。如果服务器通过一些内部可配置的机制知道旧资源永久不可用并且没有转发地址，则应该使用 410(消失)状态代码。当服务器不希望确切揭示请求被拒绝的原因时，或者当没有其他响应适用时，通常使用该状态代码。

请求行中指定的方法不允许用于请求 URI 标识的资源。响应必须包含一个允许头，其中包含所请求资源的有效方法列表。

请求所标识的资源只能生成响应实体，根据请求中发送的接受头，这些响应实体具有不可接受的内容特征。

除非是 HEAD 请求，否则响应应包括一个实体，其中包含可用实体特征和位置的列表，用户或用户代理可以从中选择最合适的一个。实体格式由内容类型标题字段中给出的媒体类型指定。根据用户代理的格式和能力，可以自动选择最合适的选项。然而，本规范没有为这种自动选择定义任何标准。

如果响应不可接受，用户代理应暂时停止接收更多数据，并询问用户是否决定采取进一步措施。

该代码类似于 401(未授权)，但表示客户端必须首先向代理进行身份验证。代理必须返回一个代理验证头字段，该字段包含适用于所请求资源的代理的质询。客户端可以用合适的代理授权报头字段重复请求。HTTP 访问身份验证在“HTTP 身份验证:基本和摘要访问身份验证”中进行了解释。

在服务器准备等待的时间内，客户端没有生成请求。客户端可以在以后的任何时间重复请求，而无需修改。

由于与资源的当前状态冲突，请求无法完成。只有在预期用户能够解决冲突并重新提交请求的情况下，才允许使用此代码。响应正文应该包含足够的信息，以便用户识别冲突的来源。理想情况下，响应实体将包含足够的信息供用户或用户代理修复问题；然而，这可能是不可能的，也不是必需的。

响应 PUT 请求时最有可能发生冲突。例如，如果正在使用版本控制，并且被放入的实体包含对资源的更改，这些更改与先前(第三方)请求所做的更改相冲突，则服务器可能会使用 409 响应来指示它无法完成请求。在这种情况下，响应实体可能会以响应内容类型定义的格式包含两个版本之间的差异列表。

请求的资源在服务器上不再可用，也不知道转发地址。这种情况被认为是永久性的。具有链接编辑功能的客户端应在用户批准后删除对请求-URI 的引用。如果服务器不知道或者没有工具来确定该状况是否是永久性的，则应该使用状态代码 404(未找到)。除非另有说明，否则此响应是可缓存的。

410 响应主要旨在通过通知接收者该资源是有意不可用的，并且服务器所有者希望删除到该资源的远程链接，来帮助完成网络维护任务。这种事件对于限时促销服务和不再在服务器站点工作的个人资源来说很常见。没有必要将所有永久不可用的资源标记为“消失”，也没有必要将标记保留任何时间长度，这由服务器所有者自行决定。

服务器拒绝接受没有定义内容长度的请求。如果客户端在请求消息中添加了包含消息体长度的有效内容长度报头字段，则客户端可以重复请求。

在服务器上测试时，一个或多个请求头字段中给出的前提条件被评估为 false。该响应代码允许客户端对当前资源元信息(头字段数据)设置先决条件，从而防止所请求的方法被应用于非预期的资源。

服务器拒绝处理请求，因为请求实体大于服务器愿意或能够处理的大小。服务器可能会关闭连接，以阻止客户端继续请求。

如果这种情况是暂时的，服务器应该包含一个“重试后”头字段，以指示这是暂时的，以及客户端可以在什么时间后重试。

服务器拒绝为请求提供服务，因为请求 URI 比服务器愿意解释的要长。只有当客户端不正确地将 POST 请求转换为具有长查询信息的 GET 请求时，当客户端陷入重定向的 URI“黑洞”(例如，重定向的 URI 前缀指向其自身的后缀)时，或者当服务器受到试图利用某些服务器中存在的安全漏洞的客户端攻击时，才会出现这种罕见的情况，这些服务器使用固定长度的缓冲区来读取或操作 Request-URI。

服务器拒绝为请求提供服务，因为请求的实体的格式不受所请求方法的所请求资源的支持。

如果请求包含范围请求头字段，并且该字段中的范围说明符值都不与所选资源的当前范围重叠，并且该请求不包含范围请求头字段，则服务器应返回带有此状态代码的响应。(对于字节范围，这意味着所有字节范围规格值的第一个字节位置大于所选资源的当前长度。)

当字节范围请求返回此状态代码时，响应应该包括一个内容范围实体头字段，指定所选资源的当前长度。此响应不得使用多部分/字节数组内容类型。

此服务器无法满足“期望请求”标头字段中给出的期望，或者，如果服务器是代理服务器，则服务器有明确的证据表明下一跳服务器无法满足该请求。

以数字“5”开头的响应状态代码表示服务器意识到自己出错或无法执行请求的情况。除了在响应 HEAD 请求时，服务器应该包括一个实体，该实体包含错误情况的解释，以及它是暂时的还是永久的情况。用户代理应向用户显示任何包含的实体。这些响应代码适用于任何请求方法。

服务器遇到意外情况，无法完成请求。

服务器不支持完成请求所需的功能。当服务器不能识别请求方法并且不能支持任何资源时，这是适当的响应。

服务器在充当网关或代理时，从它在尝试完成请求时访问的上游服务器收到无效响应。

由于服务器暂时过载或维护，服务器当前无法处理该请求。言下之意，这是一种暂时的状况，经过一段时间的拖延后会得到缓解。如果知道，延迟的长度可以在重试之后的报头中指示。如果没有给出重试后，客户端应该像处理 500 响应那样处理响应。

服务器在充当网关或代理时，没有从 URI 指定的上游服务器(例如，HTTP、FTP、LDAP)或它在尝试完成请求时需要访问的一些其他辅助服务器(例如，DNS)接收到及时的响应。

服务器不支持或拒绝支持请求消息中使用的 HTTP 协议版本。服务器表示它无法或不愿意使用与客户端相同的主要版本来完成请求，除了此错误消息。响应应该包含一个描述为什么不支持该版本以及该服务器支持哪些其他协议的实体。