HTTP状态码

RFC1945中关于状态码的定义

状态码由3个整数构成

第一个整数表示的是响应类型，范围1~5，后两个数字没有划分种类的效果，仅仅是编码标识。

状态码	类型	语义
1xx	Informational	Not used, but reserved for future use
2xx	Success	The action was successfully received, understood, and accepeted
3xx	Redirection	Further action must be taken in order to completethe request
4xx	Client Error	The request contains bad syntax or cannot be fulfilled
5xx	Server Error	The server failed to fulfill an apparently valid request

Informational 1xx

此类状态码表示临时响应，仅由status-line 和 headers 组成，并以空行表示结束。
在HTTP/1.0中没有定义任何1xx状态码，所以1xx不是对HTTP/1.0请求的有效响应。
但是它对于实验应用可能会有作用。

下面部分是HTTP/1.1的更新，源于RFC2616：
1：Continue 100——这个临时回应是通知客户端请求的初始部分已经被收到且没有被服务器拒绝。客户端应该继续发送请求的剩余部分或者请求已经发送完毕，可以忽略此响应。服务器必须在请求完成后发送最终的响应。
2：Switching Protocols 101——服务器通过 Upgrade 消息头字段理解并愿意遵守客户端的请求，以更改此连接上使用的应用程序协议。 服务器将在终止 101 响应的空行之后立即将协议切换到由响应的 Upgrade 标头字段定义的协议。 只有在这样做有利时才应该切换协议。 例如，切换到较新版本的 HTTP 比旧版本更有优势，并且在交付使用此类功能的资源时切换到实时同步协议可能更有利。

Successful 2xx

这类状态码表示客户端的请求已经被收到、理解并接受。

1：OK 200——请求已成功。 响应返回的信息取决于请求中使用的方法，例如：
GET：表示在响应中已发送了对应于请求资源的响应实体；
HEAD：响应必须只包含头信息，没有实体主体；
POST：它描述或包含了动作结果的实体
下面部分是HTTP/1.1的更新，源于RFC2616：
TRACE：终端服务器接受到的请求消息的实体。
2：Created 201——请求已完成并创建新资源，响应实体返回中的URL可以引用新创建的资源。源服务器应在使用此 Status-Code 之前创建资源。 如果不能立即执行操作，服务器必须在响应正文中包含资源何时可用的描述； 否则，服务器应响应 202（已接受）。在本规范定义的方法中，只有 POST 可以创建资源。
下面部分是HTTP/1.1的更新，源于RFC2616：
新创建的资源可以被 URI 引用在响应的实体中返回，具有 Location 标头字段给出的资源的最具体 URI。 响应应该包括一个包含资源特征和位置列表的实体，用户或用户代理可以从中选择最合适的。 实体格式由 Content-Type 标头字段中给出的媒体类型指定。 源服务器必须在返回 201 状态代码之前创建资源。 如果不能立即执行操作，服务器应该以 202（已接受）响应代替。 一个 201 响应可能包含一个 ETag 响应头字段，指示刚刚创建的请求变体的实体标签的当前值。
3：Accepted 202——已接受请求进行处理，但处理尚未完成。 该请求最终可能会或可能不会被执行，因为在实际进行处理时可能会拒绝该请求。 没有用于从诸如此类的异步操作重新发送状态代码的工具。 202 响应是故意不置可否的。 它的目的是允许服务器接受对其他进程（可能是每天只运行一次的面向批处理的进程）的请求，而不需要用户代理与服务器的连接持续到进程完成。 随此响应返回的实体应包括请求当前状态的指示，以及指向状态监视器的指针或用户预计何时可以完成请求的一些估计。
下面部分是HTTP/1.1的更新，源于RFC2616：
4：Non-Authoritative Information 203——实体标头中返回的元信息不是源服务器可用的最终集，而是从本地或第三方副本收集的。 提供的集合可以是原始版本的子集或超集。 例如，包括有关资源的本地注释信息可能会导致原始服务器已知的元信息的超集。 使用此响应代码不是必需的，仅当响应为 200 (OK) 时才适用。
5：No Content 204——服务器已完成请求，但没有新信息要发回。 如果客户端是一个用户代理，它不应该改变它的文档视图，而不是导致生成请求的文档视图。 此响应主要用于允许输入脚本或其他操作，而不会导致用户代理的活动文档视图发生更改。 响应可能包含实体标头形式的新元信息，该元信息应适用于当前在用户代理活动视图中的文档。
下面部分是HTTP/1.1的更新，源于RFC2616：
服务器已完成请求但不需要返回实体主体，并且可能希望返回更新后的元信息。 响应可以包括实体头形式的新的或更新的元信息，如果存在，应该与请求的变体相关联。如果客户端是用户代理，它不应该从导致请求的文档视图更改为发送。这个响应主要是为了允许在不改变用户代理的活动文档视图的情况下进行操作的输入，尽管任何新的或更新的元信息应该应用于当前在用户代理的活动视图中的文档。204 响应不得包含消息正文，因此始终以标头字段后的第一个空行结束。
7：Reset Content 205——服务器已经完成了请求，用户代理应该重置导致请求被发送的文档视图。此响应主要旨在允许通过用户输入进行操作输入，然后清除提供输入的表单，以便用户可以轻松启动另一个输入操作.响应不得包含实体。
8：Partial Content 206——服务器已完成对资源的部分 GET 请求。 请求必须包含指示所需范围的 Range 标头字段，并且可以包含 If-Range 标头字段以使请求有条件。响应必须包含下列头部字段：
① 要么是一个 Content-Range 头字段，指示包含在这个响应中的范围，要么是一个 multipart/byteranges Content-Type，包括每个部分的 Content-Range 字段。 如果响应中存在 Content-Length 标头字段，其值必须与消息正文中传输的 OCTET 的实际数量相匹配。
② 日期
③ETag和(或)Content-Location，如果标头将在对同一请求的 200 响应中发送
④Expires、Cache-Control 和(或) Vary，如果字段值可能与同一变体的任何先前响应中发送的值不同.
如果 206 响应是使用强缓存验证器的 If-Range 请求的结果，则响应不应包含其他实体标头。 如果响应是使用弱验证器的 If-Range 请求的结果，则响应不得包含其他实体标头； 这可以防止缓存的实体主体和更新的标头之间的不一致。 否则，响应必须包括所有实体标头，这些实体标头将与对同一请求的 200（OK）响应一起返回。
如果 ETag 或 Last-Modified 标头不完全匹配，则缓存不得将 206 响应与其他先前缓存的内容组合在一起。
不支持 Range 和 Content-Range 标头的缓存不得缓存 206（部分）响应。

Redirection 3xx

此类状态代码表示用户代理需要采取进一步的操作才能完成请求。
当且仅当后续请求中使用的方法是 GET 或 HEAD 时，用户代理可以执行所需的操作而无需与用户交互。
用户代理不应自动重定向请求超过 5 次，因为此类重定向通常表示无限循环。

下面部分是HTTP/1.1的更新，源于RFC2616：客户端应该检测无限重定向循环，因为这样的循环会为每个重定向生成网络流量。 注意：本规范的先前版本建议最多进行五次重定向。 内容开发者应该意识到可能有客户端实现了这样的固定限制。

1：Multiple Choices 300——此响应代码不直接由 HTTP/1.0 应用程序使用，但用作解释 3xx 类响应的默认值。请求的资源在一个或多个位置可用。 除非它是一个 HEAD 请求，否则响应应该包括一个包含资源特征和位置列表的实体，用户或用户代理可以从中选择最合适的。 如果服务器有首选，它应该在 Location 字段中包含 URL； 用户代理可以使用这个字段值进行自动重定向。
下面部分是HTTP/1.1的更新，源于RFC2616：请求的资源对应于一组表示中的任何一个，每个表示都有自己的特定位置，并且正在提供代理驱动的协商信息，以便用户（或用户代理）可以选择首选表示并将其请求重定向到该位置 . 除非它是一个 HEAD 请求，否则响应应该包括一个包含资源特征和位置列表的实体，用户或用户代理可以从中选择最合适的。 实体格式由 Content-Type 标头字段中给出的媒体类型指定。 根据用户代理的格式和能力，最合适的选择可以自动执行。 然而，该规范没有为这种自动选择定义任何标准。 如果服务器有首选的表示形式，它应该在 Location 字段中包含该表示形式的特定 URI； 用户代理可以使用 Location 字段值进行自动重定向。 除非另有说明，否则此响应是可缓存的。
2：Moved Permanently 301——所请求的资源已分配了一个新的永久 URL，以后对该资源的任何引用都应使用该 URL 完成。 如果可能，具有链接编辑功能的客户端应自动将对 Request-URI 的引用重新链接到服务器返回的新引用。新 URL 必须由响应中的 Location 字段给出。 除非是 HEAD 请求，否则响应的实体主体应包含一个带有新 URL 超链接的简短注释。 如果收到 301 状态代码以响应使用 POST 方法的请求，用户代理不得自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件。
注意：在收到 301 状态代码后自动重定向 POST 请求时，一些现有的用户代理会错误地将其更改为 GET 请求。
3：Moved Temporarily 302——请求的资源暂时驻留在不同的 URL 下。由于有时可能会更改重定向，客户端应继续使用 Request-URI 进行未来的请求。 URL 必须由响应中的 Location 字段给出。 除非是 HEAD 请求，否则响应的实体主体应包含一个带有指向新 URI 的超链接的简短注释。 如果收到 302 状态代码以响应使用 POST 方法的请求，则用户代理不得自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件。
注意：在收到 302 状态代码后自动重定向 POST 请求时，一些现有的用户代理会错误地将其更改为 GET 请求。
下面部分是HTTP/1.1的更新，源于RFC2616：
状态302修改表示为Found——请求的资源暂时驻留在不同的 URI 下。 由于有时可能会更改重定向，因此客户端应该继续使用 Request-URI 进行未来的请求。 此响应仅在 Cache-Control 或 Expires 标头字段指示时才可缓存。 临时 URI 应该由响应中的 Location 字段给出。 除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，带有指向新 URI 的超链接。
如果收到 302 状态代码以响应 GET 或 HEAD 以外的请求，则用户代理不得自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件。
注意：RFC 1945 和 RFC 2068 指定不允许客户端更改重定向请求的方法。 但是，大多数现有的用户代理实现将 302 视为 303 响应，对 Location 字段值执行 GET，而不管原始请求方法如何。 状态代码 303 和 307 已添加用于希望明确说明客户端期望哪种反应的服务器。
4：See Other 303——可以在不同的 URI 下找到对请求的响应，并且应该使用该资源上的 GET 方法检索。 此方法的存在主要是为了允许 POST 激活脚本的输出将用户代理重定向到选定的资源。 新的 URI 不是原始请求资源的替代引用。 不得缓存 303 响应，但对第二个（重定向的）请求的响应可能是可缓存的。 响应中的 Location 字段应该给出不同的 URI。 除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，带有指向新 URI 的超链接。
注意：许多 HTTP/1.1 之前的用户代理不理解 303 状态。 当需要考虑与此类客户端的互操作性时，可以改用 302 状态代码，因为大多数用户代理对 302 响应的反应如此处所述的 303 响应。
5：Not Modified 304——如果客户端执行了条件 GET 请求并允许访问，但文档自 If-Modified-Since 字段中指定的日期和时间以来未被修改，服务器必须响应此状态代码并且不发送 Entity- Body给客户。 响应中包含的标头字段应仅包含与缓存管理器相关的信息，或者可能已独立于实体的 Last-Modified 日期而更改的信息。 相关标头字段的示例包括：Date、Server 和 Expires。 缓存应更新其缓存的实体以反映 304 响应中给出的任何新字段值。
下面部分是HTTP/1.1的更新，源于RFC2616：
如果客户端执行了一个有条件的 GET 请求并且访问被允许，但是文档没有被修改，服务器应该用这个状态码来响应。 304 响应不得包含消息正文，因此始终由标头字段后的第一个空行终止。响应必须包含以下标头字段：
①日期，除非需要省略。 如果无时钟的源服务器遵守这些规则，并且代理和客户端将自己的日期添加到任何没有响应的响应中（如 [RFC 2068] 第 14.19 节所述），缓存将正常运行。
②ETag 和(或) Content-Location，如果标头已被发送在对同一请求的 200 响应中
③Expires、Cache-Control 和(或) Vary，如果字段值可能与同一变体的任何先前响应中发送的值不同。
如果条件 GET 使用强缓存验证器，则响应不应该包含其他实体标头。 否则（即条件 GET 使用弱验证器），响应不得包含其他实体标头； 这可以防止缓存的实体主体和更新的标头之间的不一致。
如果 304 响应指示当前未缓存的实体，则缓存必须忽略该响应并在没有条件的情况下重复该请求。
如果缓存使用收到的 304 响应来更新缓存条目，则缓存必须更新条目以反映响应中给出的任何新字段值。
6：Use Proxy 305——请求的资源必须通过 Location 字段给出的代理访问。 Location 字段给出了代理的 URI。 收件人应该通过代理重复这个单一请求。305 响应必须仅由源服务器生成。
注意：RFC 2068 并不清楚 305 旨在重定向单个请求，并且仅由源服务器生成。不遵守这些限制会产生重大的安全后果。
7：Unused 306——306状态代码在规范的前一版本中使用，不再使用，代码保留。
8：Temporary Redirect 307——请求的资源暂时驻留在不同的 URI 下。由于有时可能会更改重定向，因此客户端应该继续使用 Request-URI 进行未来的请求。此响应仅在 Cache-Control 或 Expires 标头字段指示时才可缓存。临时 URI 应该由响应中的 Location 字段给出。 除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，带有指向新 URI 的超链接，因为许多 HTTP/1.1 之前的用户代理不理解 307 状态。 因此，注释应该包含用户在新 URI 上重复原始请求所必需的信息。 如果收到 307 状态代码以响应 GET 或 HEAD 以外的请求，则用户代理不得自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件。

Client Error 4xx

4xx 类状态代码适用于客户端似乎出错的情况。 
如果客户端在收到 4xx 代码时尚未完成请求，则应立即停止向服务器发送数据。
除了响应 HEAD 请求时，服务器应该包含一个实体，其中包含对错误情况的解释，以及它是临时的还是永久的。 
这些状态代码适用于任何请求方法。
注意：如果客户端正在发送数据，TCP 上的服务器实现应该小心确保客户端在关闭输入连接之前确认收到包含响应的数据包。 
如果客户端在关闭后继续向服务器发送数据，服务器的控制器将向客户端发送一个重置数据包，这可能会在 HTTP 应用程序读取和解释之前清除客户端未确认的输入缓冲区。

1：Bad Request 400——由于语法格式错误，服务器无法理解该请求。 客户端不应该在没有修改的情况下重复请求。
2： Unauthorized 401——该请求需要用户身份验证。 响应必须包含一个 WWW-Authenticate 头字段，其中包含适用于所请求资源的质询。 客户端可以使用合适的 Authorization 标头字段重复请求。 如果请求已包含授权凭据，则 401 响应表示已拒绝对这些凭据进行授权。 如果 401 响应包含与先前响应相同的质询，并且用户代理已经尝试过至少一次身份验证，则应向用户显示响应中给出的实体，因为该实体可能包含相关诊断信息。
下面部分是HTTP/1.1的更新，源于RFC2616：
3：Payment Request 402——此代码保留供将来使用。
4：Forbidden 403——服务器理解请求，但拒绝执行请求。 授权无济于事，不应重复请求。 如果请求方法不是 HEAD 并且服务器希望公开请求未完成的原因，则应在实体主体中描述拒绝的原因。 当服务器不想透露请求被拒绝的确切原因，或者没有其他响应适用时，通常使用此状态代码。
下面部分是HTTP/1.1的更新，源于RFC2616：
如果服务器不希望将此拒绝原因信息提供给客户端，则可以使用状态代码 404（未找到）代替。
5：Not Found 404——服务器未找到与 Request-URI 匹配的任何内容。 没有迹象表明这种情况是暂时的还是永久的。 如果服务器不希望将此信息提供给客户端，则可以使用状态代码 403（禁止）代替。
下面部分是HTTP/1.1的更新，源于RFC2616：
如果服务器通过一些内部可配置的机制知道旧资源永久不可用并且没有转发地址，则应该使用 410（Gone）状态代码。 当服务器不想透露请求被拒绝的确切原因，或者没有其他响应适用时，通常使用此状态代码。
6：Method Not Allowed 405——Request-Line 中指定的方法不允许用于 Request-URI 标识的资源。 响应必须包含一个 Allow 头，其中包含所请求资源的有效方法列表。
7：Not Acceptable 406——请求标识的资源只能根据请求中发送的接受头生成具有不可接受的内容特征的响应实体。 除非是 HEAD 请求，否则响应应该包括一个实体，该实体包含可用实体特征和位置的列表，用户或用户代理可以从中选择最合适的。 实体格式由 Content-Type 标头字段中给出的媒体类型指定。 根据用户代理的格式和能力，最合适的选择可以自动执行。 然而，该规范没有为这种自动选择定义任何标准。
注意：HTTP/1.1 服务器允许根据请求中发送的 accept 标头返回不可接受的响应。 在某些情况下，这甚至可能比发送 406 响应更可取。 鼓励用户代理检查传入响应的标头以确定它是否可以接受。 如果响应可能是不可接受的，用户代理应该暂时停止接收更多数据并询问用户以决定进一步的操作。
8：Proxy Authentication Required 407——此代码类似于 401（未授权），但表示客户端必须首先向代理进行身份验证。 代理必须返回一个 Proxy-Authenticate 头字段，其中包含适用于所请求资源的代理的质询。 客户端可以使用合适的 Proxy-Authorization 头字段重复请求。
9： Request Timeout 408——在服务器准备等待的时间内，客户端没有产生请求。 客户可以在以后的任何时间不加修改地重复请求
10：Conflict 409——由于与资源的当前状态冲突，请求无法完成。 只有在预期用户能够解决冲突并重新提交请求的情况下才允许使用此代码。 响应主体应该包含足够的信息让用户识别冲突的来源。
理想情况下，响应实体将包含足够的信息供用户或用户代理解决问题； 但是，这可能是不可能的，也不是必需的。 冲突最有可能在响应 PUT 请求时发生。
例如，如果正在使用版本控制并且被 PUT 的实体包含对资源的更改，这些更改与早期（第三方）请求所做的更改冲突，服务器可能会使用 409 响应来指示它无法完成请求 . 在这种情况下，响应实体可能会包含两个版本之间的差异列表，其格式由响应 Content-Type 定义。
11：Gone 410——所请求的资源在服务器上不再可用，并且不知道转发地址。 这种情况预计将被视为永久性的。具有链接编辑能力的客户端应该在用户批准后删除对 Request-URI 的引用。如果服务器不知道，或者无法确定条件是否是永久性的，则应该使用状态代码 404（未找到）。除非另有说明，否则此响应是可缓存的。
410 响应主要旨在通过通知接收者资源有意不可用以及服务器所有者希望删除指向该资源的远程链接来协助 Web 维护任务。 对于限时促销服务和属于不再在服务器站点工作的个人的资源，此类事件很常见。 没有必要将所有永久不可用的资源标记为“消失”或将标记保留任何时间长度——这由服务器所有者自行决定。
12：Length Required 411——服务器拒绝接受没有定义 Content-Length 的请求。 如果客户端在请求消息中添加了包含消息正文长度的有效 Content-Length 标头字段，则客户端可以重复该请求。
13： Precondition Failed 412——在服务器上测试时，一个或多个请求标头字段中给出的前提条件评估为 false。 此响应代码允许客户端在当前资源元信息（标头字段数据）上放置前提条件，从而防止将请求的方法应用于预期资源以外的资源。
14：Request Entity Too Large 413——服务器拒绝处理请求，因为请求实体大于服务器愿意或能够处理的大小。 服务器可以关闭连接以防止客户端继续请求。如果条件是暂时的，服务器应该包含一个 Retry-After 头字段以指示它是临时的并且在什么时间之后客户端可以再次尝试。
15：Request-URI Too Long 414——服务器拒绝为请求提供服务，因为 Request-URI 比服务器愿意解释的长。 这种罕见的情况只有当客户端不正确地将 POST 请求转换为具有长查询信息的 GET 请求时，当客户端下降到重定向的 URI“黑洞”（例如，指向指向本身的后缀），或者当服务器受到客户端的攻击时，客户端试图利用某些服务器中存在的安全漏洞，使用固定长度的缓冲区来读取或操作 Request-URI。
16：Unsupported Media Type 415——服务器拒绝为请求提供服务，因为请求实体的格式不受所请求方法所请求资源的支持。
17：Requested Range Not Satisfiable 416——如果请求包含一个 Range request-header 字段，并且该字段中没有任何Range-specifier 值与所选资源的当前范围重叠，并且请求不包含 If-Range request-header 字段，则服务器应该返回具有此状态代码的响应。（对于字节范围，这意味着所有字节范围规范值的第一个字节位置都大于所选资源的当前长度。）当针对字节范围请求返回此状态代码时,响应应包括一个"内容范围"图元标头字段,该字段指定选定资源的当前长度。此响应不能使用multipart/byteranges content-type。
18：Expectation Failed 417——此服务器无法满足 Expect 请求标头字段中给出的期望，或者，如果服务器是代理，则服务器有明确的证据表明下一跳服务器无法满足请求。

Sever Error 5xx

以数字“5”开头的响应状态代码表示服务器知道它有错误或无法执行请求的情况。 
如果客户端在收到 5xx 代码时尚未完成请求，则应立即停止向服务器发送数据。 除了响应 HEAD 请求时，服务器应该包含一个实体，其中包含对错误情况的解释，以及它是临时的还是永久的。 
这些响应代码适用于任何请求方法，并且没有必需的标头字段。

1：Internal Server Error 500——服务器遇到意外情况，无法满足请求。
2：Not Implemented 501——服务器不支持完成请求所需的功能。 当服务器无法识别请求方法并且无法支持任何资源时，这是适当的响应。
3：Bad Gateway 502——服务器在充当网关或代理时，从它访问的上游服务器接收到无效响应以尝试完成请求。
4：Service Unavailable 503——由于服务器临时过载或维护，服务器当前无法处理请求。 言下之意，这是一种暂时的情况，会在一段时间后得到缓解。
注意：503 状态码的存在并不意味着服务器在超载时必须使用它。 一些服务器可能希望简单地拒绝连接。
下面部分是HTTP/1.1的更新，源于RFC2616：
5：Gateway Timeout 504——服务器在充当网关或代理时，没有收到来自 URI 指定的上游服务器（例如 HTTP、FTP、LDAP）或它在尝试完成时需要访问的其他辅助服务器（例如 DNS）的及时响应 要求。
注意：实施者注意：已知一些部署的代理在 DNS 查找超时时返回 400 或 500。
6：HTTP Version Not Supported 505——服务器不支持或拒绝支持请求消息中使用的 HTTP 协议版本。 服务器表示它不能或不愿意使用与客户端相同的主要版本来完成请求，而不是使用此错误消息。 响应应该包含一个实体，描述为什么不支持该版本以及该服务器支持哪些其他协议。