Status CodeMeaning
100The client should continue sending the request. This interim response is used to inform the client that part of its request has been received by the server and has not yet been rejected. The client should continue sending the remainder of the request, or, if the request has already been completed, ignore this response. The server must send a final response to the client after the request is completed.
101The server has understood the client’s request and will notify the client through the Upgrade message header to use a different protocol to complete this request. After sending the final blank line of this response, the server will switch to the protocols defined in the Upgrade header. Similar measures should be taken only when switching to a new protocol is beneficial. For example, switching to a new HTTP version is more advantageous than the old version, or switching to a real-time and synchronous protocol to transmit resources that use such features.
102A status code extended by WebDAV (RFC 2518), indicating that processing will continue.
200The request has succeeded, and the response header or data body desired by the request will be returned with this response.
201The request has been fulfilled, and a new resource has been created as needed by the request, and its URI has been returned with the Location header. If the required resource cannot be created in time, ‘202 Accepted’ should be returned.
202The server has accepted the request but has not yet processed it. Just as it may be rejected, the request may or may not be executed eventually. In the case of asynchronous operations, there is no more convenient way than sending this status code. The purpose of returning a 202 status code response is to allow the server to accept requests for other processes (for example, a batch-based operation that is executed only once a day) without making the client keep the connection to the server until the batch operation is fully completed. A response that accepts the request for processing and returns 202 should include in the returned entity some information indicating the current processing status, as well as a pointer to a processing status monitor or status prediction, so that the user can estimate whether the operation has been completed.
203The server has successfully processed the request, but the entity header metainformation returned is not a definitive set valid on the origin server, but comes from a local or third-party copy. The current information may be a subset or superset of the original version. For example, including resource metadata may cause the origin server to know a superset of the metainformation. Using this status code is not required, and it is only appropriate when the response would otherwise return 200 OK.
204The server successfully processed the request but does not need to return any entity content, and wishes to return updated metainformation. The response may return new or updated metainformation in the form of entity headers. If such header information exists, it should correspond to the requested variables. If the client is a browser, the user’s browser should retain the page that sent the request without making any changes to the document view, even if, according to the specification, the new or updated metainformation should be applied to the document in the user’s browser active view. Because a 204 response is prohibited from containing any message body, it always ends with the first blank line after the message headers.
205The server successfully processed the request and did not return any content. However, unlike a 204 response, a response returning this status code requires the requester to reset the document view. This response is mainly used to immediately reset a form after accepting user input so that the user can easily start another input. Like a 204 response, this response is also prohibited from containing any message body and ends with the first blank line after the message headers.
206The server has successfully processed a partial GET request. HTTP download tools such as FlashGet or Thunder use this type of response to implement resumable downloads or to split a large document into multiple download segments for simultaneous download.
The request must contain a Range header to indicate the range of content the client wishes to obtain, and may contain If-Range as a request condition.
The response must contain the following header fields:
Content-Range to indicate the range of content returned in this response; if it is a multipart download with Content-Type multipart/byteranges, each multipart segment should contain a Content-Range field to indicate the content range of that segment. If the response contains Content-Length, its value must match the actual number of bytes of the returned content range. Date, ETag, and/or Content-Location, if the same request should have returned a 200 response. Expires, Cache-Control, and/or Vary, if their values may differ from those of other responses to the same variables. If this response request uses If-Range strong cache validation, then this response should not contain other entity headers; if this response request uses If-Range weak cache validation, then this response is prohibited from containing other entity headers; this avoids inconsistency between the cached entity content and the updated entity header information. Otherwise, this response should contain all entity header fields that should have been returned in a 200 response. If the ETag or Last-Modified header cannot match exactly, the client cache is prohibited from combining the content returned by the 206 response with any previously cached content. Any cache that does not support Range and Content-Range headers is prohibited from caching the content returned by a 206 response.
207A status code extended by WebDAV (RFC 2518), indicating that the following message body will be an XML message and may contain a series of independent response codes depending on the number of previous subrequests.
300The requested resource has a series of selectable feedback information, each with its own specific address and browser-driven negotiation information. The user or browser can choose a preferred address for redirection. Unless this is a HEAD request, the response should include an entity with a list of resource characteristics and addresses so that the user or browser can select the most suitable redirect address. The format of this entity is determined by the format defined by Content-Type. The browser may automatically make the most appropriate choice based on the response format and its own capabilities. Of course, the RFC 2616 specification does not specify how such automatic selection should be performed. If the server itself already has a preferred feedback choice, the URI of this feedback should be indicated in Location; the browser may use this Location value as the address for automatic redirection. In addition, unless otherwise specified, this response is also cacheable.
301The requested resource has been permanently moved to a new location, and any future references to this resource should use one of the URIs returned by this response. If possible, a client with link-editing capabilities should automatically change the requested address to the address returned by the server. Unless otherwise specified, this response is also cacheable. The new permanent URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. If this is not a GET or HEAD request, the browser is prohibited from automatically performing redirection unless the user confirms it, because the conditions of the request may change as a result. Note: For some browsers using HTTP/1.0, if their POST request receives a 301 response, the subsequent redirect request will become a GET request.
302The requested resource is currently responding to requests from a different URI. Because such a redirect is temporary, the client should continue to send future requests to the original address. This response is cacheable only if specified in Cache-Control or Expires. The new temporary URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. If this is not a GET or HEAD request, the browser is prohibited from automatically performing redirection unless the user confirms it, because the conditions of the request may change as a result. Note: Although RFC 1945 and RFC 2068 do not allow clients to change the request method during redirection, many existing browsers treat a 302 response as a 303 response and use GET to access the URI specified in Location, ignoring the original request method. Status codes 303 and 307 were added to clarify what kind of reaction the server expects from the client.
303The response corresponding to the current request can be found at another URI, and the client should use GET to access that resource. This method exists mainly to allow the output of a POST request activated by a script to be redirected to a new resource. This new URI is not a substitute reference for the original resource. At the same time, a 303 response is prohibited from being cached. Of course, the second request (the redirect) may be cached. The new URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. Note: Many browsers before HTTP/1.1 cannot correctly understand the 303 status. If interaction with these browsers needs to be considered, the 302 status code should be sufficient, because most browsers handle 302 responses in exactly the way the above specification requires clients to handle 303 responses.
304If the client sent a conditional GET request and the request has been allowed, and the content of the document (since the last access or according to the request conditions) has not changed, the server should return this status code. A 304 response is prohibited from containing a message body, so it always ends with the first blank line after the message headers.
The response must contain the following header information:
Date, unless the server has no clock. If a server without a clock also follows these rules, then proxy servers and clients can add the Date field to the received response headers themselves (as specified in RFC 2068), and the caching mechanism will work normally.
ETag and/or Content-Location, if the same request should have returned a 200 response.
Expires, Cache-Control, and/or Vary, if their values may differ from those of other responses to the same variables.
If this response request uses strong cache validation, then this response should not contain other entity headers; otherwise (for example, a conditional GET request uses weak cache validation), this response is prohibited from containing other entity headers; this avoids inconsistency between the cached entity content and the updated entity header information.
If a 304 response indicates that a current entity is not cached, the cache system must ignore this response and repeatedly send a request without restrictions.
If a 304 response requiring an update to a cache entry is received, the cache system must update the entire entry to reflect the values of all fields updated in the response.
305The requested resource must be accessed through the specified proxy. The Location field will give the URI information of the specified proxy, and the recipient needs to send a separate request again to access the corresponding resource through this proxy. Only the origin server can create a 305 response. Note: RFC 2068 does not clarify that a 305 response is for redirecting a single request and can only be created by the origin server. Ignoring these restrictions may lead to serious security consequences.
306In the latest version of the specification, the 306 status code is no longer used.
307The requested resource is currently responding to requests from a different URI. Because such a redirect is temporary, the client should continue to send future requests to the original address. This response is cacheable only if specified in Cache-Control or Expires. The new temporary URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. Because some browsers cannot recognize 307 responses, the above necessary information needs to be added so that users can understand and send access requests to the new URI. If this is not a GET or HEAD request, the browser is prohibited from automatically performing redirection unless the user confirms it, because the conditions of the request may change as a result.
4001. The semantics are incorrect, and the current request cannot be understood by the server. Unless modified, the client should not resubmit this request. 2. The request parameters are incorrect.
401The current request requires user authentication. This response must contain a WWW-Authenticate information header suitable for the requested resource to ask for user information. The client may resubmit a request containing the appropriate Authorization header information. If the current request already contains Authorization credentials, then the 401 response means that server authentication has rejected those credentials. If the 401 response contains the same authentication challenge as the previous response, and the browser has already attempted authentication at least once, the browser should display the entity information contained in the response to the user, because this entity information may contain relevant diagnostic information. See RFC 2617.
402This status code is reserved for possible future needs.
403The server has understood the request but refuses to execute it. Unlike a 401 response, authentication cannot help, and this request should not be resubmitted. If this is not a HEAD request and the server wishes to explain clearly why the request cannot be executed, it should describe the reason for refusal in the entity. Of course, the server may also return a 404 response if it does not want the client to obtain any information.
404The request failed, and the resource desired by the request was not found on the server. No information can tell the user whether this situation is temporary or permanent. If the server knows the situation, it should use the 410 status code to inform that the old resource has become permanently unavailable due to some internal configuration mechanism problem, and that there is no address to jump to. The 404 status code is widely used when the server does not want to reveal why the request was rejected or when no other suitable response is available.
405The request method specified in the request line cannot be used for the requested resource. This response must return an Allow header to indicate the list of request methods that the current resource can accept. Given that PUT and DELETE methods perform write operations on server resources, most web servers do not support or do not allow the above request methods under the default configuration, and will return a 405 error for such requests.
406The content characteristics of the requested resource cannot satisfy the conditions in the request headers, so a response entity cannot be generated. Unless this is a HEAD request, the response should return an entity containing a list of entity characteristics and addresses from which the user or browser can select the most suitable one. The format of the entity is determined by the media type defined in the Content-Type header. The browser can make the best choice on its own based on the format and its own capabilities. However, the specification does not define any standard for making such automatic selection.
407Similar to a 401 response, except that the client must authenticate on the proxy server. The proxy server must return a Proxy-Authenticate to perform the authentication challenge. The client can return Proxy-Authorization header information for verification. See RFC 2617.
408Request timeout. The client did not complete sending a request within the time the server was prepared to wait. The client can resubmit this request at any time without any changes.
409The request cannot be completed due to a conflict with the current state of the requested resource. This code may only be used in situations where the user is considered able to resolve the conflict and will resubmit a new request. The response should contain enough information for the user to discover the source of the conflict. Conflicts usually occur when processing PUT requests. For example, in an environment using version checking, if the version information attached to a PUT request to modify a specific resource conflicts with a previous (third-party) request, then the server should return a 409 error to inform the user that the request cannot be completed. At this time, the response entity is likely to contain a comparison of the differences between the two conflicting versions so that the user can resubmit a new merged version.
410The requested resource is no longer available on the server, and there is no known forwarding address. Such a situation should be considered permanent. If possible, a client with link-editing capabilities should delete all references to this address after obtaining user permission. If the server does not know or cannot determine whether this situation is permanent, it should use the 404 status code. Unless otherwise specified, this response is cacheable. The purpose of the 410 response is mainly to help website administrators maintain the website, notify users that the resource is no longer available, and that the server owner hopes that all remote links pointing to this resource will also be deleted. Such events are common in limited-time, value-added services. Likewise, the 410 response is also used to notify the client that on the current server site, a resource that originally belonged to an individual is no longer available. Of course, whether all permanently unavailable resources need to be marked as ‘410 Gone’, and how long this mark needs to be kept, depends entirely on the server owner.
411The server refuses to accept the request without a defined Content-Length header. After adding a valid Content-Length header indicating the length of the request message body, the client can submit the request again.
412The server failed to satisfy one or more of the preconditions given in the request header fields during verification. This status code allows the client to set preconditions in the request metainformation (request header field data) when obtaining a resource, thereby preventing the request method from being applied to resources other than the desired content.
413The server refuses to process the current request because the size of the entity data submitted by the request exceeds the range the server is willing or able to process. In this case, the server may close the connection to prevent the client from continuing to send this request. If this situation is temporary, the server should return a Retry-After response header to inform the client how long to wait before retrying.
414The length of the requested URI exceeds the length the server can interpret, so the server refuses to service the request. This is relatively rare. Common cases include: a form submission that should have used POST becomes a GET method, causing the query string to be too long. Redirect URI ‘black holes’, for example, each redirect includes the old URI as part of the new URI, causing the URI to become too long after several redirects. The client is attempting to exploit a security vulnerability in some servers to attack the server. Such servers use fixed-length buffers to read or operate on the requested URI. When the parameters after GET exceed a certain value, a buffer overflow may occur, causing arbitrary code execution[1]. Servers without such vulnerabilities should return the 414 status code.
415For the method of the current request and the requested resource, the entity submitted in the request is not in a format supported by the server, so the request is rejected.
416If the request contains a Range request header, and any data range specified in Range does not overlap with the available range of the current resource, and the request does not define an If-Range request header, then the server should return the 416 status code. If Range uses byte ranges, then this situation means that the first byte position of all data ranges specified in the request exceeds the length of the current resource. The server should also include a Content-Range entity header when returning the 416 status code to indicate the length of the current resource. This response is also prohibited from using multipart/byteranges as its Content-Type.
417The expectation specified in the Expect request header cannot be satisfied by the server, or the server is a proxy server and has clear evidence that the content of Expect cannot be satisfied at the next node on the current route.
421The number of connections from the IP address where the current client is located to the server exceeds the maximum range permitted by the server. Usually, the IP address here refers to the client address seen from the server (such as the user’s gateway or proxy server address). In this case, the calculation of the number of connections may involve more than one end user.
422The number of connections from the IP address where the current client is located to the server exceeds the maximum range permitted by the server. Usually, the IP address here refers to the client address seen from the server (such as the user’s gateway or proxy server address). In this case, the calculation of the number of connections may involve more than one end user.
422The request format is correct, but it cannot be responded to because it contains semantic errors. (RFC 4918 WebDAV) 423 Locked The current resource is locked. (RFC 4918 WebDAV)
424The current request failed due to an error in a previous request, for example PROPPATCH. (RFC 4918 WebDAV)
425Defined in the WebDav Advanced Collections draft, but not present in the WebDAV Ordered Collections Protocol (RFC 3658).
426The client should switch to TLS/1.0. (RFC 2817)
449A Microsoft extension, indicating that the request should be retried after appropriate operations have been performed.
500The server encountered an unexpected condition that prevented it from completing the processing of the request. Generally, this problem occurs when there is an error in the server’s program code.
501The server does not support a certain function required by the current request. When the server cannot recognize the request method and cannot support its requests for any resource.
502The server acting as a gateway or proxy received an invalid response from the upstream server while attempting to execute the request.
503Due to temporary server maintenance or overload, the server is currently unable to process the request. This situation is temporary and will recover after a period of time. If the delay time can be estimated, the response may contain a Retry-After header to indicate this delay time. If this Retry-After information is not given, the client should handle it in the same way as a 500 response. Note: The existence of the 503 status code does not mean that the server must use it when overloaded. Some servers simply wish to refuse client connections.
504The server acting as a gateway or proxy did not receive a timely response from the upstream server (the server identified by the URI, such as HTTP, FTP, LDAP) or an auxiliary server (such as DNS) while attempting to execute the request. Note: Some proxy servers return 400 or 500 errors when DNS queries time out.
505The server does not support, or refuses to support, the HTTP version used in the request. This implies that the server cannot or is unwilling to use the same version as the client. The response should contain an entity describing why the version is not supported and which protocols the server supports.
506Extended by the Transparent Content Negotiation Protocol (RFC 2295), indicating that the server has an internal configuration error: the requested negotiated variant resource is configured to use itself in transparent content negotiation, and therefore is not a suitable focus in a negotiation process.
507The server cannot store the content necessary to complete the request. This situation is considered temporary. WebDAV (RFC 4918)
509The server has reached its bandwidth limit. This is not an official status code, but it is still widely used.
510The policy required to obtain the resource has not been satisfied. (RFC 2774)

(This is part 1 of 2 of the same post.)

HTTP 状态码 - 维基百科