| HTTP Status Code | Status Code Meaning |
|---|
| 100 | The client should continue sending the request. This temporary response notifies the client that part of its request has been received by the server and has not been rejected. The client should continue sending the remaining part of the request, or ignore this response if the request is already complete. The server must send a final response to the client after the request is completed. |
| 101 | The server has understood the client's request and will notify the client to adopt a different protocol to complete this request through the Upgrade header. After sending the last empty line of this response, the server will switch to the protocols defined in the Upgrade header. Such measures should only be taken when switching to a new protocol is more beneficial. For example, switching to a newer HTTP version has advantages over the old version, or switching to a real-time and synchronous protocol to transmit resources that utilize such features. |
| 102 | A status code extended by WebDAV (RFC 2518), indicating that processing will continue. |
| 200 | The request has been successful, and the response header or data body desired by the request will be returned with this response. |
| 201 | The request has been fulfilled, and a new resource has been created according to the needs of the request, and its URI has been returned with the Location header. If the required resource cannot be created in a timely manner, a '202 Accepted' should be returned. |
| 202 | The 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 asynchronous operation scenarios, 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 from other processes (such as a batch processing operation that is executed only once a day) without requiring the client to remain connected to the server until the batch processing operation is completed. A response that accepts the request for processing and returns a 202 status code should include some information indicating the current status of processing in the returned entity, as well as pointers to processing status monitors or status predictions so that users can estimate whether the operation has been completed. |
| 203 | The server has successfully processed the request, but the returned entity header meta-information is not a valid determined set on the original 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 metadata of resources may cause the original server to know the superset of metadata. Using this status code is not mandatory, and it is only appropriate if the response would return 200 OK without using this status code. |
| 204 | The server successfully processed the request but does not need to return any entity content and wishes to return updated meta-information. The response may return new or updated meta-information in the form of entity headers. If these headers exist, they 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 producing any changes in the document view, even though new or updated meta-information should be applied to the document in the user's browser's active view according to the specification. Since a 204 response is prohibited from containing any message body, it always ends with the first empty line after the message header. |
| 205 | The 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 reset the form immediately 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 empty line after the message header. |
| 206 | The server has successfully processed part of the GET request. HTTP download tools like FlashGet or Thunder use such responses to implement breakpoint resumption or split a large document into multiple download segments for simultaneous downloading. The request must include a Range header to indicate the content range desired by the client, and may include If-Range as a request condition. The response must include the following header fields: Content-Range to indicate the range of content returned in this response; if it is a multi-segment download with Content-Type multipart/byteranges, each multipart segment should include a Content-Range field to indicate the content range of that segment. If the response includes Content-Length, its value must match the actual number of bytes in the content range it returns. 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 corresponding to other responses of the same variable. If the response request uses If-Range strong cache validation, this response should not include other entity headers; if the response request uses If-Range weak cache validation, this response is prohibited from including other entity headers; this avoids inconsistencies between cached entity content and updated entity header information. Otherwise, this response should include all entity header fields that should be returned in a 200 response. If the ETag or Last-Modified headers cannot be precisely matched, client caches should be 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. |
| 207 | A status code extended by WebDAV (RFC 2518), indicating that the subsequent message body will be an XML message and may contain a series of independent response codes depending on the number of previous sub-requests. |
| 300 | The requested resource has a series of alternative 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 appropriate redirection 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 the browser's own capabilities. Of course, the RFC 2616 specification does not stipulate how such automatic selection should be performed. If the server itself already has a preferred feedback choice, then this feedback's URI should be specified in Location; the browser may use this Location value as the address for automatic redirection. In addition, unless specified otherwise, this response is also cacheable. |
| 301 | The requested resource has been permanently moved to a new location, and any future references to this resource should use one of the URIs returned in this response. If possible, clients with link editing capabilities should automatically modify the requested address to the address fed back from the server. Unless specified otherwise, 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 entity of the response should include 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 redirecting unless confirmed by the user, because the conditions of the request may change as a result. Note: For some browsers using the HTTP/1.0 protocol, when their POST requests receive a 301 response, the subsequent redirection request will become a GET method. |
| 302 | The requested resource temporarily resides under a different URI. Since the redirect might be altered on occasion, the client SHOULD continue to use the original URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field. The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). If the 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 it can be confirmed by the user, since this might change the conditions under which the request was issued. Note: RFC 1945 and RFC 2068 specify that the client MUST NOT change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client. |
| 303 | The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable. The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303. |
| 304 | If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields. The response MUST include the following header fields: Date, unless the server does not have a clock. A server without a clock MUST NOT send a 304 response unless it is prepared to accept the risk that its response may be in error. ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request. Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant. If the conditional GET used a strong cache validator, the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. If a 304 response indicates an entity not currently cached, then the cache MUST ignore the response and repeat the request without the conditional. If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response. |
| 305 | The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient MUST repeat the request via the proxy. 305 responses MUST only be generated by origin servers. Note: RFC 2068 did not specify that 305 responses could only be generated by origin servers. Ignoring this requirement can have security consequences. |
| 306 | The 306 status code was used in a previous version of the specification, but is no longer used. |
| 307 | The requested resource temporarily resides under a different URI. Since the redirect may be altered on occasion, the client SHOULD continue to use the original URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field. The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s), since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI. If the 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 it can be confirmed by the user, since this might change the conditions under which the request was issued. |
| 400 | 1. The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. 2. The request parameters are invalid. |
| 401 | The request requires user authentication. The response MUST include a WWW-Authenticate header field containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field. If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented with the entity that was given in the response, since that entity might include relevant diagnostic information. See RFC 2617. |
| 402 | This status code is reserved for future use. |
| 403 | The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead. |
| 404 | The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable. |
| 405 | The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource. Since the PUT, DELETE, and other methods that may modify resources are often disabled by default on web servers, such requests will typically return a 405 error. |
| 406 | The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request. Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection. |
| 407 | Similar to 401, but authentication is required for a proxy server. The proxy MUST return a Proxy-Authenticate header field containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field. See RFC 2617. |
| 408 | The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time. |
| 409 | Since and been requested resource's current state exists conflicts, the request cannot be completed. This code only allows to be used in the following cases to be used: user is believed that can solve conflicts, and will repeat the new request. The response should include enough information to help user discover the conflict's source. Conflict usually occurs during processing of POST requests. For example, in a situation where a POST request's data to a specific resource is modified by a third party, then the server should return a 409 error, informing user that the request cannot be completed. In this case, the response entity may include two conflict versions, to help user re-submit the new version. |
| 410 | The requested resource in the server is no longer available, and there is no known forwarding address. This condition should be considered permanent. If possible, the client who requested the resource should be deleted all the references to this address. If the server does not know or cannot determine this condition is permanent, then it should use the status code 404. Unless otherwise specified, this response is cacheable. 410 response is used to help the webmaster maintain the website, notify users that the resource is no longer available, and the server owner wants to delete all references to this resource. This event is common in limited, tiered services. Similarly, 410 response is also used to notify the client that the original resource is no longer available. Of course, whether to mark all permanently unavailable resources as '410 Gone', and whether to maintain this mark for a longer time is completely dependent on the server owner. |
| 411 | Server refuses to receive a request without defining Content-Length header. After adding an appropriate Content-Length header, the client can again submit the request. |
| 412 | Server is unable to validate a request header field by the given pre-condition(s). This status code allows the client to set a pre-condition in the request's meta information (the data of the request header field) to avoid the request method being applied to its content outside of the desired resource. |
| 413 | Server refuses to process the current request, because the request submitted entity data size exceeded the server's willingness or the ability to handle the range. This situation, the server can be closed to prevent the client from continuing to send this request. If this condition is temporary, the server should return a Retry-After response, to inform the client that it can be retried after the given time. |
| 414 | Request's URI length exceeded the server's capacity to interpret, and as a result, the server refuses to provide service to the request. This is quite rare, and the typical case includes: the form of the HTTP request is changed to GET, causing the query string (Query String) to be too long. Redirect URI "black hole", for example, each redirect will use the old URI as a new URI, causing the URI to be too long after multiple redirects. The client is trying to take advantage of some existing security vulnerabilities attack the server. These servers use a fixed length buffer to read or process the URI, when GET after the parameter exceeds a certain value, it may cause a buffer overflow, resulting in arbitrary code execution [1]. No such vulnerability exists on the server, should return a 414 status code. |
| 415 | For the current request method and the requested resource, the request submitted entity is not supported by the server. Therefore, the request is denied. |
| 416 | If the request included a Range request header, and the range specified any data range with the current resource's available range is not matching, and the request did not include a If-Range request header, then the server should return a 416 status code. If Range uses a byte range, then this is the situation in which the range specified all data ranges's first byte position is larger than the current resource's length. The server should also return a 416 status code, containing a Content-Range entity header to indicate the current resource's length. This response is prohibited using multipart/byteranges as its Content-Type. |
| 417 | The expectation that the request specified is not met by the server, or the server is a proxy that has a clear and obvious evidence of the next node on the current path. |
| 421 | The connection count from the current client's IP address to the server is exceeding the server's permitted maximum count. Typically, the client's IP address is viewed as the client's address (like the user's gateway or proxy server address). In this case, the count of the connection may involve more than one end-user. |
| 422 | The connection count from the current client's IP address to the server is exceeding the server's permitted maximum count. Typically, the client's IP address is viewed as the client's address (like the user's gateway or proxy server address). In this case, the count of the connection may involve more than one end-user. |
| 422 | The request format is correct, but the semantic error is not allowed. (RFC 4918 WebDAV)423 Locked current resource is locked.(RFC 4918 WebDAV) |
| 424 | Since the previous request has an error, the current request failed, for example PROPPATCH.(RFC 4918 WebDAV) |
| 425 | In WebDav Advanced Collections draft, but not appear in the _WebDAV order set protocol (RFC 3658). |
| 426 | Client should switch to TLS/1.0.(RFC 2817) |
| 449 | By Microsoft extension, represent the request should be retried after the appropriate operation. |
| 500 | Server encountered an unforeseen condition, that is why it could not complete the request. Generally, this problem will appear when the server program code error. |
| 501 | Server does not support the current request required some functionality. When the server can not recognize the request method, and can not support its request for any resource. |
| 502 | As a gateway or proxy working server attempts to execute the request, from the upstream server receives an invalid response. |
| 503 | Since the temporary server maintenance or overload, the server is currently unable to process the request. This condition is temporary, and will be restored in a certain time. If it is possible to estimate the delay time, then the response can include a Retry-After header to indicate this delay time. If no Retry-After information is given, then the client should handle the 500 response as it is. Note: 503 status code exists does not necessarily mean that the server must use it. Some servers just want to refuse the client's connection. |
| 504 | As a gateway or proxy working server attempts to execute the request, failed to receive a response from the upstream server (URI identifier of the server, for example HTTP, FTP, LDAP) or auxiliary server (for example DNS). Note: Some proxy servers may return a 400 or 500 error when DNS query time-out. |
| 505 | Server does not support, or refuse support in the request in using HTTP version. This suggests that the server can not or will not use the same version as the client. The response should include a description of why the version is not supported and the server supports which protocols. |
| 506 | By the _Opaque content negotiation protocol (RFC 2295) extends, represents the server has an internal configuration error: the requested negotiation resource is configured for the opaque content negotiation in which the requested resource is used, therefore, in a negotiation process is not a suitable focus. |
| 507 | Server can not store the content required for the request. This condition is considered temporary. WebDAV(RFC 4918) |
| 509 | Server reaches the bandwidth limit. This is not an official status code, but is still widely used. |
| 510 | Get resource required strategy is not met. (RFC 2774) |
