| Http status code | Status Code Meaning |
|---|
| 100 | The client should continue to send requests. This temporary response is used to inform the client that part of its request has been received by the server and has not been rejected. The client should continue to send the remainder of the request, or ignore this response if the request is complete. The server must send a final response to the client when the request is complete. |
| 101 | The server has understood the client's request and will notify the client via the Upgrade message header to use a different protocol to complete the request. After sending the last blank line of this response, the server will switch to those protocols defined in the Upgrade message header. This should only be done if it is more beneficial to switch to a new protocol. For example, switching to a new version of HTTP is more advantageous than an older version, or switching to a real-time and synchronous protocol to deliver resources that take advantage of such features. |
| 102 | Status codes, extended by WebDAV (RFC 2518), represent 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 as required 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. |
| 202 | The server has accepted the request, but has not yet processed it. Just as it may be rejected, eventually the request may or may not be executed. In the context of asynchronous operations, there is nothing more convenient than sending this status code. The purpose of returning a response with a 202 status code is to allow the server to accept requests from other processes (such as a batch-based operation that is executed only once a day) without having to keep the client connected to the server until the batch operation is fully completed. A response that accepts a request for processing and returns a 202 status code SHOULD include in the returned entity some information indicating the current state of the process, as well as a pointer to a processing status monitor or status prediction so that the user can estimate whether the operation has completed. |
| 203 | The server has successfully processed the request, but the returned entity header meta-information is not a definitive set valid on the original server, but a copy from a local or third party. The current information may be a subset or superset of the original version. For example, metadata containing resources may cause the original server to know the meta-information super. Use of this status code is not required and is only appropriate if the response would have returned 200 OK without it. |
| 204 | The server processed the request successfully, but does not need to return any physical content and wants to return updated meta-information. The response may return new or updated meta-information in the form of entity headers. If such headers exist, they should correspond to the requested variables. If the client is a browser, then the user's browser SHOULD retain the page on which the request was sent without any document view changes, even though the new or updated meta-information SHOULD, according to the specification, be applied to the document in the active view of the user's browser. Since the 204 response is prohibited from containing any message body, it always ends with the first blank line after the message header. |
| 205 | The server successfully processed the request and returned nothing. Unlike the 204 response, however, the response that returns this status code asks the requester to reset the document view. This response is primarily being used to reset the form immediately after accepting user input so that the user can easily start another input. Like the 204 response, this response is prohibited from containing any message body and ends with the first blank line after the message header. |
| 206 | The server has successfully processed part of the GET request. HTTP download tools like FlashGet or Thunderbolt use this type of response to perform intermittent downloads or to break up a large document into multiple download segments at the same time. The request must contain a Range header to indicate the range of content the client wishes to receive, and may contain an If-Range as a request condition. The response must contain the following header fields: Content-Range to indicate the scope of the content returned in this response; in the case of a multi-segment download with a Content-Type of multipart/byteranges, each multipart segment should contain a Content-Range field indicating the scope of the content in that segment. If the response contains a Content-Length, its value must match the true 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 be different from other responses with the same variables. Expires, Cache-Control, and/or Vary, if their values may be different from the values of other previous responses for the same variables. This response SHOULD NOT contain other entity headers if the request uses If-Range strong cache validation, and SHOULD NOT contain other entity headers if the request uses If-Range weak cache validation; this avoids inconsistencies between cached entity content and updated entity header information. Otherwise, this response SHOULD contain all the entity header fields that should have been returned in all the 200 responses that should have been returned. If the ETag or Last-Modified headers do not match exactly, the client-side cache SHOULD prohibit combining the content returned in response 206 with any previously cached content. Any cache that does not support the Range and Content-Range headers is prohibited from caching the content returned by the 206 response. |
| 207 | The status code, as extended by WebDAV (RFC 2518), means that the subsequent message body will be an XML message and may contain a series of separate response codes, depending on the number of previous subrequests. |
| 300 | The requested resource has a series of alternative return messages, each with its own specific address and browser-driven negotiation information. The user or browser is able to select a preferred address for redirection on their own. Unless this is a HEAD request, the response should include an entity that is a list of resource characteristics and addresses from which the user or browser can select the most appropriate redirection address. The format of this entity is determined by the format of the Content-Type definition. The browser may automatically make the most appropriate selection based on the format of the response and the browser's own capabilities. Of course, the RFC 2616 specification does not specify how such an automatic choice should be made. If the server itself already has a preferred choice of return, then the URI of this return should be specified in Location; the browser may use this Location value as the address for automatic redirection. In addition, this response is also cacheable unless otherwise specified. |
| 301 | The requested resource has been permanently moved to the new location, and any future references to it should use one of the several URIs returned in this response. If possible, clients with link editing capabilities should automatically change the requested address to the one returned from the server. This response is also cacheable unless otherwise specified. 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 short description. If this is not a GET or HEAD request, the browser is therefore prohibited from automatically redirecting unless confirmed by the user, as the terms of the request may change as a result. Note: For some browsers using the HTTP/1.0 protocol, when they send a POST request and get a 301 response, the next redirection request will be a GET. |
| 302 | The requested resource now temporarily responds to the request from a different URI. Since this redirection is temporary, the client should continue to send future requests to the original address. This response is only cacheable 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 short description. If this is not a GET or HEAD request, then the browser is prohibited from automatically redirecting unless confirmed by the user, as the terms of the request may change as a result. Note: Although the RFC 1945 and RFC 2068 specifications do not allow the client to change the method of the request on redirection, many existing browsers treat the 302 response as a 303 response and use GET to access the URI specified in the Location, ignoring the method of the original request. Status codes 303 and 307 have been added to clarify what response the server expects from the client. |
| 303 | The response to the current request can be found at another URI and the client should access that resource using GET. This method exists primarily to allow script-activated POST request output to be redirected to a new resource. This new URI is not an alternative reference to the original resource. Also, the 303 response is forbidden to be cached. Of course, the second request (redirection) 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 short description. Note: Many browsers prior to HTTP/1.1 versions do not properly understand the 303 state. If interaction with these browsers needs to be considered, the 302 status code should do the trick, since most browsers handle the 302 response in exactly the same way that the above specification requires the client to handle the 303 response. |
| 304 | The server SHOULD return this status code if the client sends a conditional GET request that has been allowed and the content of the document (either since the last visit or according to the conditions of the request) has not changed.304 responses are prohibited from containing message bodies, and therefore always end with the first blank line after the message header. The response MUST contain the following headers: Date, unless the server does not have a clock. If a server without a clock follows these rules, then the proxy server and the client can add the Date field to the incoming response header on their own (as specified in RFC 2068), and the caching mechanism will work correctly.ETag and/or Content-Location, if the same request would have returned a 200 response.Expires Expires, Cache-Control, and/or Vary, if the value may be different from the value corresponding to other previous responses for the same variable. If this response request uses strong cache validation, then this response should not contain other entity headers; otherwise (e.g., a conditional GET request uses weak cache validation), this response is prohibited from containing other entity headers; this avoids inconsistencies between cached entity content and updated entity header information. If a 304 response indicates that an entity is not currently cached, the caching system must ignore the response and repeat the request without the restriction. If a 304 response is received requesting that a cache entry be updated, the caching system MUST update the entire entry to reflect the values of all fields updated in the response. |
| 305 | The requested resource must be accessed through the specified proxy. the Location field will give information about the URI where the specified proxy is located. the recipient will need to send a separate request repeatedly to access the resource through this proxy. Only the original server can create a 305 response. Note: It is not clear from RFC 2068 that a 305 response is intended to redirect a single request and can only be built by the original server. Ignoring these restrictions could lead to serious security consequences. |
| 306 | In the latest version of the specification, the 306 status code is no longer used. |
| 307 | The requested resource now temporarily responds to the request from a different URI. Since such redirects are temporary, clients should continue to send future requests to the original address. This response is only cacheable 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 short description. Because some browsers do not recognise the 307 response, the above information needs to be added so that the user can understand and request access to the new URI. If this is not a GET or HEAD request, then the browser prohibits automatic redirection, unless confirmed by the user, because the conditions of the request may change. |
| 400 | 1. There is a semantic error and the current request cannot be understood by the server. Unless modified, the client should not repeatedly submit this request. 2, the request parameters are wrong. |
| 401 | The current request requires user authentication. The response must contain a WWW-Authenticate header for the requested resource to ask for user information. The client can repeatedly submit a request that contains the appropriate Authorisation header information. If the current request already contains Authorisation credentials, then the 401 response means that the server verifies that those credentials have been rejected. If the 401 response contains the same authentication query as the previous response, and the browser has already attempted authentication at least once, then the browser SHOULD present the user with the entity information contained in the response, as this entity information may contain relevant diagnostic information. See RFC 2617. |
| 402 | This status code is reserved for possible future requirements. |
| 403 | The server has understood the request but refuses to execute it. Unlike a 401 response, authentication does not provide any help, and this request should not be resubmitted. If this is not a HEAD request and the server wants to be able to speak clearly about why the request cannot be executed, then the reason for the refusal should be described within the entity. Of course the server can also return a 404 response if it does not wish to give the client any information. |
| 404 | The request failed, the requested resource was not found on the server. There is no information to tell the user whether the situation is temporary or permanent. If the server is aware of the situation, it should use the 410 status code to inform the user that the old resource is permanently unavailable due to some internal configuration mechanism and that there is no redirection available. 404 is widely used when the server does not want to reveal why the request was rejected or when no other suitable response is available. |
| 405 | The request method specified in the request line cannot be used to request the corresponding resource. The response must return an Allow header indicating the list of request methods that are acceptable for the current resource. Given that the PUT and DELETE methods write to the resource on the server, most web servers do not support these request methods or do not allow them by default, and will return a 405 error for such requests. |
| 406 | The content characteristics of the requested resource do not satisfy the conditions in the request header, and the response entity cannot be generated. Unless this is a HEAD request, the response should return an entity containing a list of entity properties and addresses from which the user or browser can select the most appropriate. The format of the entity is determined by the media type defined in the Content-Type header. Browsers can make their own best choices based on the format and their own capabilities. However, the specification does not define any criteria for making such automatic choices. |
| 407 | Similar to the 401 response, except that the client MUST authenticate at the proxy server. The proxy server MUST return a Proxy-Authenticate for identity interrogation. The client MAY return a Proxy-Authorization header for authentication. See RFC 2617. |
| 408 | Request timeout. The client did not complete sending a request within the time the server was prepared to wait. The client may resubmit the request at any time without making any changes. |
| 409 | The request could not be completed due to a conflict with the current state of the requested resource. This code is only allowed to be used if the user is deemed to be able to resolve the conflict and resubmit a new request. The response should contain enough information for the user to discover the source of the conflict. Conflicts typically occur in the processing of PUT requests. For example, in a version-checking environment, if the version information attached to a PUT submitted to modify a particular resource conflicts with a previous (third-party) request, the server should return a 409 error informing the user that the request could not be completed. In this case, the response entity is likely to contain a comparison of the differences between the two conflicting versions so that the user can resubmit the new version after the merge. |
| 410 | The requested resource is no longer available on the server and does not have any known forwarding address. Such a condition should be considered permanent. If possible, clients with link editing capabilities should remove all references to this address with the user's permission. If the server does not know or cannot determine whether this condition is permanent, then a 404 status code should be used. Unless otherwise noted, this response is cacheable.410 The purpose of the response is primarily to assist the webmaster in maintaining the site by informing the user that the resource is no longer available and that the server owner wishes all remote connections to this resource to be removed as well. This type of event is common in time-limited, value-added services. Similarly, the 410 response is used to notify clients that a resource that originally belonged to an individual on the current server site is no longer available. Of course, it is entirely up to the server owner as to whether all permanently unavailable resources need to be marked as '410 Gone' and how long this marking needs to be maintained. |
| 411 | The server refuses to accept requests without the Content-Length header defined. After adding a valid Content-Length header indicating the length of the request message body, the client may submit the request again. |
| 412 | The server failed to satisfy one or more of the prerequisites when verifying that they were given in the request's header field. This status code allows the client to set preconditions in the request's meta-message (request header field data) when obtaining a resource, thus preventing the request method from being applied to resources other than the content it desires. |
| 413 | The server refuses to process the current request because it submits entity data of a size larger than the server is willing or able to handle. In this case, the server may close the connection to prevent the client from continuing to send this request. If this condition is temporary, the server should return a Retry-After response header to inform the client how much time it can retry after. |
| 414 | The length of the request's URI exceeds the length that the server can interpret, so the server refuses to serve the request. This is rare, and is often the case when a form submission that should have used the POST method becomes a GET method, resulting in a long Query String. Redirect URI "black holes", such as using the old URI as part of the new URI with each redirect, resulting in a long URI after several redirects. Clients are attempting to attack servers by exploiting security vulnerabilities that exist in some servers. Such servers use a fixed-length buffer to read or manipulate the URI of a request, and when the parameters after a GET exceed a certain value, a buffer overflow may occur, leading to arbitrary code execution [1]. Servers without such vulnerabilities should return a 414 status code. |
| 415 | For the currently requested method and requested resource, the entity submitted in the request is not in a format supported in the server, so the request is rejected. |
| 416 | If the request contains a Range request header, and any data ranges specified in the Range do not overlap with the ranges available for the current resource, and the If-Range request header is not defined in the request, then the server should return a 416 status code. If Range uses byte ranges, then this is the case if the first byte position of all the data ranges specified in the request exceeds the length of the current resource. The server should also include a Content-Range entity header that specifies the length of the current resource along with the 416 status code. This response is also prohibited from using multipart/byteranges as its Content-Type. |
| 417 | The expected content specified in the request header Expect cannot be fulfilled by the server, or this server is a proxy server that has clear evidence that the content of Expect cannot be fulfilled at the next node in the current route. |
| 421 | The number of connections to the server from the IP address where the current client is located exceeds the maximum allowed by the server. Typically, the IP address here refers to the client's address as seen from the server (e.g., the user's gateway or proxy server address). In this case, the connection count may involve more than one end user. |
| 422 | The number of connections to the server from the IP address of the current client exceeds the maximum allowed by the server. Typically, the IP address here refers to the client's address as seen from the server (e.g., the user's gateway or proxy server address). In this case, the connection count may involve more than one end user. |
| 422 | The request was formatted correctly, but could not be responded to because it contained semantic errors. (RFC 4918 WebDAV) 423 Locked The current resource is locked. (RFC 4918 WebDAV) |
| 424 | The current request failed due to an error that occurred in a previous request, such as PROPPATCH.(RFC 4918 WebDAV) |
| 425 | Defined in the WebDav Advanced Collections draft, but does not appear in the WebDAV Sequential Collections Protocol (RFC 3658). |
| 426 | Clients should switch to TLS/1.0.(RFC 2817) |
| 449 | Extended by Microsoft to represent that requests should be retried after the appropriate action has been performed. |
| 500 | The server encountered an unanticipated condition that prevented it from completing processing of the request. Typically, this problem occurs when there is an error in the server's program code. |
| 501 | The server does not support a particular feature that is required for the current request. When the server is unable to recognise the requested method and is unable to support its request for any resource. |
| 502 | A server working as a gateway or proxy receives an invalid response from an upstream server when it tries to execute a request. |
| 503 | The server is currently unable to process the request due to temporary server maintenance or overload. This condition is temporary and will be restored after some time. If a delay can be expected, the response may include a Retry-After header to indicate the delay. If this Retry-After information is not given, then 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 if it is overloaded. Some servers simply wish to deny the client a connection. |
| 504 | A server working as a gateway or proxy that attempts to perform a request fails to receive a timely response from an upstream server (a server identified by a URI, such as HTTP, FTP, LDAP) or a secondary server (such as DNS). Note: Some proxy servers return a 400 or 500 error when the DNS lookup times out. |
| 505 | The server does not support, or refuses to support, the version of HTTP used in the request. This implies that the server is unable or unwilling to use the same version as the client. The response should contain an entity that describes why the version is not supported and which protocols the server supports. |
| 506 | Extended by the Transparent Content Negotiation Protocol (RFC 2295) to represent an internal misconfiguration on the part of the server: the requested Negotiation Variant resource is configured to use itself in transparent content negotiation, and is therefore not an appropriate focus in a negotiation process. |
| 507 | The server is unable to store the content necessary to complete the request. This condition is considered temporary.WebDAV (RFC 4918) |
| 509 | The server reached its bandwidth limit. This is not an official status code, but is still widely used. |
| 510 | The policy required to obtain the resource was not unmet. (RFC 2774) |