客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。

服务器已经理解了客户端的请求，并将通过 Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到 在 Upgrade 消息头中定义的那些协议。:
只有在切换新的协议更有好处的时候才应该采取类似措施。例如，切换到新的 HTTP 版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特 性的资源。

请求成功。成功的意义根据请求所使用的方法不同而不同.

GET: 资源已被提取，并作为响应体传回客户端.
HEAD: 实体头已作为响应头传回客户端
POST: 经过服务器处理客户端传来的数据，适合的资源作为响应体传回客户端.
TRACE: 服务器收到请求消息作为响应体传回客户端。

请求成功，而且有一个新的资源已经依据请求的需要而建立，通常这是 PUT 方法得到的响应码。

服务器已接受请求，但尚未处理。正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。在异步操作的场合下，没有比发送这个状态码更方便的做法了。返回 202 状态码的响应的目的是允许服务器接受其他过程的请求（例如某个每天只执行一次的基于批处理的操作），而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回 202 状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息，以及指向处理状态监视器或状态预测的指针，以便用户能够估计操作是否已经完成。

服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝，如果不是上述情况，使用 200 状态码才是最合适的。

该响应没有响应内容，只有响应头，响应头也可能是有用的。用户代理可以根据新的响应头来更新对应资源的缓存信息。

告诉用户代理去重置发送该请求的窗口的文档视图。

当客户端通过使用 range 头字段进行文件分段下载时使用该状态码

该请求有多种可能的响应，用户代理或者用户必须选择它们其中的一个。服务器没有任何标准可以遵循去代替用户来进行选择。

该状态码表示所请求的 URI 资源路径已经改变，新的 URL 会在响应的 Location:头字段里找到。

该状态码表示所请求的 URI 资源路径临时改变，并且还可能继续改变。因此客户端在以后访问时还得继续使用该 URI.新的 URL 会在响应的 Location:头字段里找到。

服务器发送该响应用来引导客户端使用 GET 方法访问另外一个 URI.

告诉客户端，所请求的内容距离上次访问并没有变化。客户端可以直接从浏览器缓存里获取该资源。

所请求的资源必须统过代理才能访问到。由于安全原因，该状态码并未受到广泛支持。

这个状态码已经不再被使用，当初它被用在 HTTP 1.1 规范的旧版本中。

服务器发送该响应用来引导客户端使用相同的方法访问另外一个 URI 来获取想要获取的资源。新的 URL 会在响应的 Location:头字段里找到。与 302 状态码有相同的语义，且前后两次访问必须使用相同的方法 (GET
POST).

所请求的资源将永久的位于另外一个 URI 上。新的 URL 会在响应的 Location:头字段里找到。与 301 状态码有相同的语义，且前后两次访问必须使用相同的方法 (GET
POST).

因发送的请求语法错误，服务器无法正常读取。

需要身份验证后才能获取所请求的内容，类似于 403 错误。不同点是.401 错误后，只要正确输入帐号密码，验证即可通过。

该状态码被保留以供将来使用。创建此代码最初的目的是为数字支付系统而用，然而，到现在也没投入使用。

客户端没有权利访问所请求内容，服务器拒绝本次请求。

服务器找不到所请求的资源。由于经常发生此种情况，所以该状态码在上网时是非常常见的。

该请求使用的方法被服务器端禁止使用，RFC2616 中规定，GET 和 HEAD 方法不能被禁止。

在进行服务器驱动内容协商后，没有发现合适的内容传回给客户端。

类似于状态码 401，不过需要通过代理才能进行验证。

客户端没有在服务器预备等待的时间内完成一个请求的发送。这意味着服务器将会切断和客户端的连接。在其他浏览器中，这种响应更常见一些，例如 Chrome 和 IE9, 目的是为了使用 HTTP 预连机制加快浏览速度。同时注意，一些服务器不发送此种响应就直接切断连接。

该请求与服务器的当前状态所冲突。

所请求的资源已经被删除。

因服务器在本次请求中需要 Content-Length 头字段，而客户端没有发送。所以，服务器拒绝了该请求。

服务器没能满足客户端在获取资源时在请求头字段中设置的先决条件。

请求实体大小超过服务器的设置的最大限制，服务器可能会关闭 HTTP 链接并返回 Retry-After 头字段。

客户端请求所包含的 URI 地址太长，以至于服务器无法处理。

服务器不支持客户端所请求的媒体类型，因此拒绝该请求。

请求中包含的 Range 头字段无法被满足，通常是因为 Range 中的数字范围超出所请求资源的大小。

在请求头 Expect 中指定的预期内容无法被服务器满足。

超文本咖啡壶控制协议（英语：Hyper Text Coffee Pot Control Protocol，缩写 HTCPCP）是由 IETF 虚构的一种协议。这个协议在文档 RFC 2324（1998 年 4 月 1 日发布）中定义，是一个恶搞 RFC。该协议被设计为一个类似 HTTP 的协议，可以用于控制、监测和诊断咖啡壶，后来也被拓展到茶壶；该协议有时也可以视作一种早期的物联网实验。

服务器遇到未知的无法解决的问题。

服务器不支持该请求中使用的方法，比如 POST 和 PUT.只有 GET 和 HEAD，是 RFC2616 规范中规定服务器必须实现的方法。

服务器作为网关且从上游服务器获取到了一个无效的 HTTP 响应。

由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。如果能够预计延迟时间，那么响应中可以包含一个 Retry-After:头用以标明这个延迟时间。如果没有给出这个 Retry-After:信息，那么客户端应当以处理 500 响应的方式处理它。同时，这种情况下，一个友好的用于解释服务器出现问题的页面应当被返回，并且，缓存相关的 HTTP 头信息也应该包含，因为通常这种错误提示网页不应当被客户端缓存。

服务器作为网关且不能从上游服务器及时的得到响应返回给客户端。

服务器不支持客户端发送的 HTTP 请求中所使用的 HTTP 协议版本。