1 Definition of status code
The description of each status code is as follows, including a description of the methods it can follow and any meta information required in the response.
1.1 Informational 1xx
This type of status code represents a provisional response and consists only of a status line and optional headers, and ends with a blank line. There is no required title for this type of status code. Since HTTP/1.0 does not define any 1xx status codes, the server must not send 1xx responses to HTTP/1.0 clients unless under experimental conditions.
Even if the client does not want to receive a 100 (Continue) status message, the client must be prepared to accept one or more 1xx status responses before accepting regular responses. User agents may ignore unexpected 1xx status responses.
The proxy must forward the 1xx response unless the connection between the proxy and its client has been closed, or unless the proxy itself requests to generate a 1xx response. (For example, if
The proxy adds the "Expect: 100-Continue" field when forwarding the request, so it does not need to forward the corresponding 100 (Continue) response. )
1.1.1 100 continue
Customers should continue their request. The provisional response is used to notify the client that the initial part of the request has been received and has not been rejected by the server. The client should continue to send the remaining requests or, if the request has been completed, ignore the response. After the request is completed, the server must send the final response.
1.1.2 101 Exchange Protocol
The server understands and is willing to use the "upgrade message header" field to satisfy the client's request to change the application protocol used on this connection. The server will switch the protocol to the protocol defined by the "upgrade" header field of the response immediately after terminating the blank line of the 101 response.
The protocol should only be switched when it is advantageous. For example, switching to a new version of HTTP is better than an old version, and when transferring resources that use such functions, it may be advantageous to switch to a real-time synchronization protocol.
2.2 Successful 2xx
This type of status code indicates that the customer's request has been successfully received, understood and accepted.
2.2.1 200 OK
The request has been successful. The information returned in the response depends on the method used in the request, for example:
Send the entity corresponding to the requested resource in the response;
HEAD sends the entity header field corresponding to the requested resource in the response without any message body;
POST describes or contains the entity of the operation result;
Track the entity containing the request message received by the final server.
2.2.2 201 Created
The request was completed and resulted in the creation of a new resource. The newly created resource can be referenced by the URI returned in the response entity, where the most specific URI is given by the Location header field. The response should include an entity that contains a list of resource characteristics and locations, from which the user or user agent can choose the most suitable one. The entity format is specified by the media type provided in the Content-Type header field. The origin server must create the resource before returning the 201 status code. If the operation cannot be performed immediately, the server should replace it with a 202 (accepted) response.
The 201 response may contain an ETag response header field, which indicates the current value of the entity tag of the requested variant just created.
2.2.3 202 Accept
The request has been accepted for processing, but processing has not yet been completed. The request may or may not be executed eventually, because the request may not be allowed in actual processing. There is no function to resend the status code from such an asynchronous operation.
The 202 response was intentionally rejected. Its purpose is to allow the server to accept requests from some other process (perhaps a batch-oriented process that runs only once a day) without the need for a user agent to connect to the server until the process is complete. The entity returned with this response should include an indication of the current status of the request, as well as a pointer to the status monitor or some estimate of when the user can expect to complete the request.
2.2.4 203 non-authoritative information
The meta information returned in the entity header is not the authoritative set available to the original server, but is collected from a local or third-party copy. The presented set can be a subset or superset of the original version. For example, including local annotation information about resources may result in a superset of meta-information known to the origin server. This response code is not required and only applies when the response is 200 (OK).
2.2.5 204 No content
The server has completed the request, but does not need to return the entity, and may want to return updated meta information. The response may include new or updated meta-information in the form of an entity header, and if it exists, it should be associated with the requested variant.
If the client is a user agent, the document view that caused the request to be sent should not be changed. Although any new or updated meta-information should be applied to the document currently in the active view of the user agent, the response is primarily intended to allow input operations without causing changes to the active document view of the user agent.
The 204 response must not contain the message body, so it is always terminated by the first blank line after the header field.
2.2.6 205 Reset content
The server has completed the request, and the user agent should reset the document view that caused the request to be sent. The response is mainly to allow the input of an operation through user input, and then clear the form of giving the input so that the user can easily initiate another input operation. The response must not contain entities.
2.2.7 Part 206
The server has completed part of the GET request for the resource. The request must include a Range header field indicating the required range, and may include an If-Range header field to make the request a conditional request.
The response must include the following header fields:
-Content-Range标头字段（第14.16节）指示
此响应包含的范围，或多部分/字节范围
Content-Type，包括每个部分的Content-Range字段。如果一个
响应中存在Content-Length标头字段，
值必须与在
邮件正文。
-日期
-ETag和/或Content-Location（如果标头已发送）
在对同一请求的200条回复中
-如果字段值可能会过期，缓存控制和/或变化
与先前的任何回复中发送的相同
变体
If the 206 response is the result of an If-Range request using a strong cache validator, the response should not contain other entity headers. If the response is the result of an If-Range request using a weak validator, the response MUST not include other entity headers; this can prevent inconsistencies between the cached entity and the updated header. Otherwise, the response must include all entity headers that return a 200 (OK) response to the same request.
If the ETag or Last-Modified header does not match exactly, the cache must not combine the 206 response with other previously cached content, see 13.5.4.
Caches that do not support Range and Content-Range headers must not cache 206 (partial) responses.
1.3 Redirect 3xx
This type of status code indicates that the user agent needs to take further steps to satisfy the request. If and only if the method used in the second request is GET or HEAD, the user agent can perform the required operation without interacting with the user. The client should detect an infinite redirection loop, because such a loop generates network traffic for each redirection.
注意：本规范的先前版本建议使用
最多五个重定向。内容开发人员应注意
可能会有客户实施这样的固定
局限性。
1.3.1 300 multiple choices
The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent-driven negotiation information is provided so that the user (or user agent) can select the preferred representation and redirect its request to that position.
Unless it is a HEAD request, the response should include an entity containing a list of resource characteristics and locations from which the user or user agent can choose the most suitable one. The entity format is specified by the media type provided in the "Content Type" header field. Depends on format and function
The user agent can automatically execute the most appropriate selection. However, the specification does not define any criteria for such automatic selection.
If the server has a preferred representation, it should include the specific URI of that representation in the "location" field; user agents can use the "location" field value for automatic redirection. Unless otherwise noted, this response is cacheable.
1.3.2 301 Moved Permanently
The requested resource has been assigned a new permanent URI, and any future references to the resource should use one of the returned URIs. The client with the link editing function should automatically relink the reference to the Request-URI to one or more new references returned by the server when possible. Unless otherwise noted, this response is cacheable.
The new permanent URI should be given by the Location field in the response. Unless the request method is HEAD, the entity of the response should contain a short hypertext comment with a hyperlink to the new URI.
If a 301 status code is received in response to a request other than GET or HEAD, the user agent must not automatically redirect the request unless the user can confirm it, as this may change the conditions for making the request.
注意：在之后自动重定向POST请求时
收到301状态代码，一些现有的HTTP / 1.0用户代理
将错误地将其更改为GET请求。
1.3.3 Found 302
The requested resource is temporarily located under another URI. Since the redirection may sometimes change, the client should continue to use the Request-URI for future requests. This response can be cached only when indicated by the Cache-Control or Expires header field.
The temporary URI should be given by the Location field in the response. Unless the request method is HEAD, the entity of the response should contain a short hypertext comment with a hyperlink to the new URI.
If a 302 status code is received in response to a request other than GET or HEAD, the user agent must not automatically redirect the request unless the user can confirm it, as this may change the conditions for making the request.
注意：RFC 1945和RFC 2068指定不允许客户端
更改重定向请求的方法。但是，大多数
现有的用户代理实现将302视为303
响应，无论位置字段值如何执行GET
原始请求方法。状态码303和307具有
为希望明确指出哪个服务器添加了
期望客户有种反应。
1.3.4 303 View other
The response to the request can be found under a different URI, and the GET method on the resource should be used to retrieve the request. This method exists mainly to allow the output of the POST activation script to redirect the user agent to the selected resource. The new URI cannot replace the originally requested resource. The 303 response must not be cached, but the response to the second (redirected) request may be cacheable.
The Location field in the response should provide a different URI. Unless the request method is HEAD, the entity of the response should contain a short hypertext comment with a hyperlink to the new URI.
注意：许多HTTP / 1.1之前的用户代理不了解303
状态。当需要考虑与此类客户端的互操作性时，
因为大多数用户代理都会做出反应，所以可以改用302状态代码
302响应，如此处针对303所述。
1.3.5 304 not modified
If the client has performed a conditional GET request and allowed access, but the document has not been modified, the server should respond with this status code. The 304 response must not contain the message body, so it is always terminated by the first blank line after the header field.
The response must include the following header fields:
If the server without a clock source complies with these rules, and the proxy and client add their own date to any response received without a response, the cache will operate normally.
-ETag和/或Content-Location（如果标头已发送）
在对同一请求的200条回复中
-如果字段值可能会过期，缓存控制和/或变化
与先前的任何回复中发送的相同
变体
If the conditional GET uses a strong cache validator, the response should not contain other entity headers. Otherwise (that is, the conditional GET uses a weak validator), the response must not contain other entity headers; this prevents inconsistencies between the cached entity and the updated header.
If the 304 response indicates an entity that is not currently cached, the cache must ignore the response and repeat the request without conditions.
If the cache uses the received 304 response to update the cache entry, the cache must update the entry to reflect any new field values given in the response.
1.3.6 305 Use proxy
The requested resource must be accessed through the proxy given in the location field. The location field provides the URI of the agent. It is expected that the recipient will repeat this single request through the proxy. The 305 responses can only be generated by the origin server.
注意：RFC 2068尚不清楚305是否旨在重定向
单个请求，并且仅由原始服务器生成。不
遵守这些限制会带来严重的安全后果。
1.3.7 306 (not used)
The 306 status code was used in the previous version of the specification and is no longer used, and the code is retained.
1.3.8 307 Temporary Redirect
The requested resource is temporarily located under another URI. Since the redirection may sometimes change, the client should continue to use the Request-URI for future requests. This response can be cached only when indicated by the Cache-Control or Expires header field.
The temporary URI should be given by the Location field in the response. Unless the request method is HEAD, the responding entity should contain a short hypertext comment with a hyperlink to the new URI, because many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the comment should contain the information necessary for the user to repeat the original request on the new URI.
If a 307 status code is received in response to a request other than GET or HEAD, the user agent must not automatically redirect the request unless the user can confirm it, as this may change the conditions for making the request.
1.4 Client error 4xx
The status code 4xx class is used when the client seems to have gone wrong. In addition to responding to the HEAD request, the server should include an entity that contains a description of the error condition and whether it is temporary or permanent. These status codes apply to any request method. The user agent should display any contained entities to the user.
If the client is sending data, before the server closes the incoming connection, server implementations using TCP should take care to ensure that the client confirms the receipt of the packet containing the response. If the client continues to send data to the server after it is closed, the server's TCP stack will send a reset packet to the client, which may erase the client's unacknowledged input buffer, and then the HTTP application can read and interpret it they.
1.4.1 400 Bad Request
The server cannot understand the request due to a syntax error. Customers should not repeat the request without modification.
1.4.2 401 Unauthorized
The request requires user authentication. The response must include a WWW-Authenticate header field, which contains the challenge applicable to the requested resource. The client can repeat the request using the appropriate Authorization header field. If the request already contains authorization credentials, the 401 response indicates that authorization for these credentials has been denied. If the 401 response contains the same challenge as the previous response, and the user agent has attempted authentication at least once, the entity given in the response should be provided to the user, as this entity may include relevant diagnostic information. HTTP access authentication is in "HTTP Authentication: Basic and Digest Access Authentication".
1.4.4 402 Payment required
This code is reserved for future use.
1.4.4 403 Forbidden
服务器理解了该请求，但拒绝执行该请求。授权将无济于事，并且不应重复该请求。如果请求方法不是HEAD，并且服务器希望公开为什么未满足请求，则应在实体中描述拒绝原因。如果服务器不希望将此信息提供给客户端，则可以使用状态代码404（未找到）来代替。
1.4.5 404找不到
服务器找不到与请求URI匹配的任何内容。没有迹象表明这种情况是暂时的还是永久的。如果服务器通过某种内部可配置的机制得知旧资源永久不可用并且没有转发地址，则应使用410（已消失）状态代码。如果服务器不希望确切显示请求被拒绝的原因，或者没有其他响应可应用时，通常使用此状态代码。
1.4.6 405 方法不允许
Request-URI所标识的资源不允许使用Request-Line中指定的方法。响应必须包括一个Allow标头，其中包含所请求资源的有效方法列表。
1.4.7 406不可接受
由请求标识的资源仅能够生成响应实体，该响应实体具有根据请求中发送的接受标头不可接受的内容特征。
除非它是HEAD请求，否则响应应包括一个实体，其中包含可用实体特征和位置的列表，用户或用户代理可以从中选择最合适的一个。实体格式由Content-Type标头字段中提供的媒体类型指定。根据用户代理的格式和功能，可以自动执行最合适的选择。但是，该规范没有为这种自动选择定义任何标准。
注意：允许HTTP / 1.1服务器返回以下响应：
根据在
请求。在某些情况下，这甚至可能比发送
406回应。鼓励用户代理检查的标题
确定是否可以接受的传入响应。
如果响应是不可接受的，则用户代理应暂时停止接收更多数据，并向用户查询有关进一步操作的决定。
1.4.8 需要 407代理身份验证
此代码类似于401（未经授权），但表示客户端必须首先使用代理对其进行身份验证。代理务必返回一个Proxy-Authenticate头域，其中包含适用于所请求资源的代理的质询。客户可以用合适的代理授权头域重复请求。HTTP访问身份验证在“ HTTP身份验证：基本和摘要访问身份验证”。
1.4.9 408 请求超时
在服务器准备等待的时间内，客户端未发出请求。客户端可以在以后的任何时间重复请求而无需修改。
1.4.10 409冲突
由于与资源的当前状态存在冲突，因此无法完成请求。仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许使用此代码。响应正文应包含足够的内容
供用户识别冲突源的信息。理想情况下，响应实体应包括足够的信息以供用户或用户代理解决问题。但是，这可能是不可能的，也不是必需的。
响应PUT请求最有可能发生冲突。例如，如果正在使用版本控制，并且正在PUT的实体包括对资源的更改，该更改与早期（第三方）请求所做的更改冲突，则服务器可能会使用409响应来指示它无法完成请求。在这种情况下，响应实体可能会以响应Content-Type定义的格式包含两个版本之间差异的列表
1.4.12 411 长度要求
服务器拒绝在没有定义Content-Length的情况下接受请求。如果客户端在请求消息中添加了包含消息主体长度的有效Content-Length头字段，则客户端可以重复该请求。
1.4.13 412 前提条件失败
在服务器上测试时，在一个或多个请求标头字段中给出的前提条件被评估为false。此响应代码允许客户端在当前资源元信息（标头字段数据）上放置先决条件，从而防止所请求的方法应用于除预期资源之外的其他资源。
1.4.14 413请求实体太大
服务器拒绝处理请求，因为请求实体大于服务器愿意或能够处理的实体。服务器可以关闭连接，以防止客户端继续请求。
如果条件是临时的，则服务器应包括Retry- After标头字段以指示它是临时的，并且客户端可以在什么时间之后重试。
1.4.15 414 请求URI太长
服务器拒绝处理请求，因为Request-URI的长度比服务器愿意解释的时间长。仅当客户端将不正确的POST请求转换为带有长查询信息的GET请求，客户端下降到重定向的URI“黑洞”（例如，指向URI的重定向URI前缀）时，才会发生这种罕见情况后缀），或者当服务器受到客户端的攻击时，该客户端试图使用固定长度的缓冲区来读取或处理Request-URI来利用某些服务器中存在的安全漏洞。
1.4.16 415 不支持的媒体类型
服务器拒绝为请求提供服务，因为请求的实体的格式不受请求的方法所请求的资源支持。
1.4.17 416 请求的范围不满足
如果请求包含Range请求标头字段，并且该字段中没有任何range-specifier值与所选资源的当前范围重叠，并且请求未包含此请求，则服务器应返回带有此状态代码的响应包含If-Range请求标头字段。（对于字节范围，这意味着所有字节范围规范值的第一个字节位置都大于所选资源的当前长度。）
当针对字节范围请求返回此状态代码时，响应应包含指定所选择资源的当前长度的Content-Range实体标头字段。此响应绝对不能使用multipart / byteranges内容类型。
1.4.18 417 预期失败
此服务器无法满足在Expect请求标头字段中给出的期望，或者，如果该服务器是代理，则该服务器有明确的证据表明下一跳服务器无法满足该请求。
1.5 服务器错误5xx
以数字“ 5”开头的响应状态代码表示服务器知道服务器已出错或无法执行请求的情况。除响应HEAD请求外，服务器应包括一个实体，该实体包含错误情况的说明，以及它是暂时还是永久的情况。用户代理应该向用户显示任何包含的实体。这些响应代码适用于任何请求方法。
1.5.1 500内部服务器错误
服务器遇到意外情况，阻止其满足请求。
1.5.2 501 未实现
服务器不支持满足请求所需的功能。当服务器无法识别请求方法并且不支持任何资源时，这是适当的响应。
1.5.3 502错误的网关
该服务器在充当网关或代理的同时，从尝试访问该请求的上游服务器接收到无效响应。
1.5.4 503服务不可用
由于暂时的服务器过载或维护，服务器当前无法处理该请求。言外之意是，这是一个暂时的状况，经过一段时间的延迟后会缓解。如果知道的话，延迟的长度可以在Retry-After头中指出。如果没有给出Retry-After，则客户端应该像处理500响应那样处理响应。
注意：503状态代码的存在并不意味着
服务器过载时必须使用它。一些服务器可能希望
简单地拒绝连接。
1.5.5 504网关超时
该服务器虽然充当网关或代理，但没有收到由URI指定的上游服务器（例如HTTP，FTP，LDAP）或尝试完成访问所需访问的其他某些辅助服务器（例如DNS）的及时响应。请求。
注意：实施者注意：已知一些已部署的代理
DNS查找超时时返回400或500。
1.5.6 505 HTTP版本不受支持
服务器不支持或拒绝支持请求消息中使用的HTTP协议版本。服务器会指示它无法或不愿意使用与客户端相同的主要版本来完成请求 ，但带有此错误消息除外。响应应该包含一个实体，描述为什么不支持该版本以及该服务器支持哪些其他协议。