Tip: Ctrl F Quick Find| Http status code | Meaning of status code |
|---|---|
| 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 yet been rejected. The client should continue to send the remainder of the request, or ignore the 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 use a different protocol to complete the request by Upgrade the message header. After sending the last blank line of the response, the server will switch to the protocol defined in the Upgrade header. Similar measures should be taken only when it is more beneficial to switch to a new protocol. For example, switching to a new HTTP version 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 code extended by WebDAV(RFC 2518), which indicates that processing will continue. |
| 200 | The request was successful, and the desired response header or body of the request is returned with the 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 information. If the required resources cannot be established in time, '202 Accepted' should be returned '. |
| 202 | The server accepted the request but has not yet processed it. Just as it may be denied, ultimately the request may or may not be executed. In the case of asynchronous operations, there is nothing more convenient than sending this status code. The purpose of a response that returns a 202 status code is to allow the server to accept requests for other processes (such as a batch-based operation that executes only once a day) without having to keep the client connected to the server until the batch operation is complete. Responses that accept the requested processing and return a 202 status code should include some information in the returned entity indicating the current status of the processing, as well as a pointer to the processing status monitor or status prediction so that the user 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 deterministic set valid on the original server, but a copy from a local or third party. The current information may be a subset or a superset of the original version. For example, the metadata containing a resource may cause the origin server to know the super of the meta information. The use of this status code is not required and is appropriate only if the response returns 200 OK without this status code. |
| 204 | The server successfully processed the request, but does not need to return any entity content and expects to return updated meta information. The response may return new or updated meta information in the form of an entity header. If such header information exists, it should be echoed with the requested variable. If the client is a browser, then the user browser should retain the page that sent the request without making any changes in the document view, even if the new or updated meta information should be applied to the document in the active view of the user browser according to the specification. Because the 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 returned nothing. However, unlike 204 responses, responses that return this status code require the requester to reset the document view. The response is mainly used to reset the form immediately after accepting user input so that the user can easily start another input. Like the 204 response, the 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 a partial GET request. HTTP download tools such as FlashGet or Thunderbolt use such responses to resume transmission or to decompose a large document into multiple download segments for simultaneous download. The request must contain Range header information to indicate the content range that the client wants, 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 multi-segment download with Content-Type of multipart/byteranges, each multipart segment should contain a Content-Range field to indicate the content range of this segment. If the response contains Content-Length, then 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 its value may be different from the value corresponding to other previous responses of the same variable.If this response request uses If-Range strong cache verification, then this response should not contain other entity headers. If the request of this response uses If-Range weak cache verification, then this response is forbidden to contain other entity headers. This avoids inconsistency 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 the 200 response. If the ETag or Last-Modified header does not match exactly, the client cache should disallow the content returned by the 206 response from being combined with any previously cached content. Any cache that does not support Range and the Content-Range header disables caching of the content returned by the 206 response. |
| 207 | The status code extended by WebDAV(RFC 2518) indicates 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 range 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 the entity of a list of resource properties and addresses from which the user or browser can select the most appropriate redirect address. The format of this entity is determined by the format defined by the Content-Type. 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 automatic selection should take place. If the server itself already has a preferred feedback selection, the URI of this feedback should be indicated in the Location; the browser may use this Location value as the address for automatic redirection. In addition, unless otherwise specified, 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 several URIs returned by this response. If possible, the client with the link editing function should automatically modify the requested address to the address fed back from 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 responding entity should contain a hyperlink to the new URI and a short description. If this is not a GET or HEAD request, the browser prohibits automatic redirection unless confirmed by the user, as the conditions of the request may change as a result. Note: For some browsers that use the HTTP/1.0 protocol, when the POST request they send gets a 301 response, the subsequent redirect request will become GET. |
| 302 | The requested resource is currently being served temporarily from a different URI. Since this redirect is temporary, the client should continue to send subsequent requests to the original URI. This response is cacheable only if it is explicitly specified in the Cache-Control or Expires headers. The new temporary URI should be returned in the Location header of the response. Unless it is a HEAD request, the response body shall contain a hyperlink to the new URI along with a brief description. If the request is not a GET or HEAD request, the browser must not automatically follow redirects unless the user explicitly confirms them, because the request’s conditions might change as a result. Note: Although RFC 1945 and RFC 2068 do not permit clients to change the request method during redirection, many existing browsers treat a 302 response as a 303 response and issue a GET request to the URI specified in the Location header, disregarding the original request method. Status codes 303 and 307 were introduced to clarify the server’s expected client behavior. |
| 303 | The response corresponding to the current request can be found under a different URI, and the client should access that resource using the GET method. This method exists primarily to allow POST requests initiated by a script to redirect their output to a new resource. This new URI is not a replacement reference for the original resource. Meanwhile, 303 responses must not be cached. Of course, the second request (the redirect) may be cached. The new URI should be returned in the Location header of the response. Unless it is a HEAD request, the response body shall contain a hyperlink to the new URI along with a brief description. Note: Many browsers prior to HTTP/1.1 do not correctly handle the 303 status code. If you need to account for interactions with these browsers, the 302 status code should suffice, since most browsers handle 302 responses in exactly the manner that the specification prescribes for clients when processing 303 responses. |
| 304 | If the client sends a conditional GET request and the request is allowed, and the content of the document has not changed (since the last access or based on the condition of the request), the server should return this status code. 304 the response is prohibited from including the message body, it always ends with the first empty line after the message header. The response must contain the following header information: Date, unless the server does not have a clock. If the server without a clock also obeys these rules, then the proxy server and the client can add the Date field to the received response header (as specified in RFC 2068), and the caching mechanism will work normally. ETag and/or Content-Location, if the same request should return a 200 response. Expires,Cache-Control, and/or Vary, if its value may be different from the value corresponding to other previous responses of the same variable.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 prohibits the inclusion of other entity headers; This avoids inconsistencies between the cached entity content and the updated entity header information. If a 304 response indicates that an entity is not currently cached, the cache system must ignore the response and repeatedly send requests that do not contain the constraint. If a 304 response is received that requires an update to a cache entry, the cache system must update the entire entry to reflect the values of all the fields that were updated in the response. |
| 305 | The requested resource must be accessed through the specified proxy. The Location domain will give the URI information where the specified proxy is located, and the receiver needs to send a separate request repeatedly to access the corresponding resource through this proxy. Only the original server can establish a 305 response. Note: The RFC 2068 does not explicitly 305 that the response is intended to redirect a single request and can only be established by the origin server. Ignoring these restrictions could lead to serious security consequences. |
| 306 | In the latest version of the specification, 306 status codes are no longer used. |
| 307 | The requested resource is currently being served temporarily from a different URI. Since this redirect is temporary, the client should continue to send subsequent requests to the original URI. This response is cacheable only if it is explicitly specified in the Cache-Control or Expires headers. The new temporary URI should be returned in the Location header of the response. Unless it is a HEAD request, the response body shall contain a hyperlink to the new URI along with a brief description. Because some browsers do not recognize 307 responses, it is necessary to include the above required information so that users can understand the situation and issue a request to the new URI. If the request is not a GET or HEAD request, the browser must not automatically follow redirects unless the user explicitly confirms them, because the request’s conditions might change as a result. |
| 400 | 1, the semantic error, the current request cannot be understood by the server. Unless modified, the client should not submit this request repeatedly. 2. The request parameter is incorrect. |
| 401 | The current request requires user authentication. The response must contain a WWW-Authenticate header for the requested resource to ask the user for information. The client can repeatedly submit a request containing the appropriate Authorization header information. If the current request already contains Authorization certificates, the 401 response indicates that the server has verified that those certificates have been rejected. If the 401 response contains the same authentication challenge as the previous response, and the browser has attempted authentication at least once, the browser should show the user 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 potential future needs. |
| 403 | The server has understood the request, but is refusing to execute it. Unlike 401 responses, authentication does not help, and the request should not be submitted repeatedly. If this is not a HEAD request, and the server wants to be able to explain why the request cannot be executed, then the reason for the rejection should be described in the entity. Of course, the server can also return a 404 response if it does not want the client to get any information. |
| 404 | The request failed because the requested resource was not found on the server. No information can tell the user whether the situation is temporary or permanent. If the server knows the situation, it should use the 410 status code to inform the old resource that it has been permanently unavailable due to some internal configuration mechanism problem and does not have any address to jump. 404 this status code is widely used when the server does not want to reveal why the request was rejected or 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 a list of request methods that the current resource can accept. Since the PUT and DELETE methods write to resources on the server, most web servers do not support or do not allow the above request methods by default, and 405 errors are returned for such requests. |
| 406 | The content characteristics of the requested resource do not satisfy the conditions in the request header, so a response entity cannot be generated. Unless this is a HEAD request, the response should return an entity that contains a list of entity properties and addresses from which the user or browser can choose the most appropriate. The format of the entity is determined by the media type defined in the Content-Type header. The browser can make the best choice according to the format and its own capabilities. However, the specification does not define any criteria for making such automatic selections. |
| 407 | Similar to a 401 response, except that the client must authenticate with the proxy server. The proxy server must return a Proxy-Authenticate header to initiate authentication. The client may return a Proxy-Authorization header for authentication. See RFC 2617. |
| 408 | Request timed out. The client did not complete the sending of a request within the time the server was prepared to wait. The client can submit this request again 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 supposed to be able to resolve the conflict and resubmit the 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 an environment where version checking is used and the version information attached to a PUT-submitted modification request for 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. At this point, it is likely that the response entity will contain a comparison of the differences between the two conflicting versions so that the user can resubmit the merged new version. |
| 410 | The 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, the client with the link editing function should remove all references to this address with the user's permission. If the server does not know or cannot determine whether the condition is permanent, then the 404 status code should be used. Unless otherwise noted, this response is cacheable. The purpose of 410 response is mainly to help the webmaster maintain the website, inform the user that the resource is no longer available, and the server owner wants all remote connections to this resource to be deleted. Such incidents are common in time-limited, value-added services. Similarly, 410 responses are used to inform the client that a resource that originally belonged to an individual is no longer available at the current server site. Of course, whether you need to mark all permanently unavailable resources as '410 Gone', and how long you need to keep this mark, depends entirely on the server owner. |
| 411 | The server refused to accept the request without defining the Content-Length header. After adding a valid Content-Length header that indicates the length of the request message body, the client can submit the request again. |
| 412 | The server fails to meet one or more of the prerequisites when it verifies that they are given in the header fields of the request. This status code allows the client to set preconditions in the meta information (request header field data) of the request when acquiring the resource, thus preventing the request method from being applied to resources other than its desired content. |
| 413 | The server is refusing to process the current request because the request is submitting more entity data than the server is willing or able to process. In this case, the server can close the connection to prevent the client from continuing to send the request. If the condition is temporary, the server should return a Retry-After response header to tell the client how much time it can take to try again. |
| 414 | The length of the requested URI exceeds the limit that the server can parse, so the server is refusing to service the request. This is relatively uncommon. Typical scenarios include form submissions that should use the POST method but instead use the GET method, resulting in an excessively long query string. “Black hole” redirect URIs, where each redirect appends the original URI as part of the new URI, can result in an excessively long URI after several redirects. The client is attempting to exploit a security vulnerability present on certain servers to attack them. These servers use fixed-length buffers to read or process the URI of incoming requests. When the number of parameters following the GET request exceeds a certain threshold, a buffer overflow may occur, potentially leading to arbitrary code execution [1]. Servers that do not have this type of vulnerability should return a 414 Status Code. |
| 415 | For the currently requested method and requested resource, the entity submitted in the request is not in the format supported in the server, so the request is rejected. |
| 416 | If the request contains the Range request header, any data range specified in the Range does not coincide with the available range of the current resource, and the If-Range request header is not defined in the request, the server should return the 416 status code. If the Range uses a byte range, 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 along with 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. |
| 417 | The expected content specified in the request header Expect cannot be satisfied by the server, or the server is a proxy server that has clear evidence that the Expect content cannot be satisfied on the next node of the current route. |
| 421 | The number of connections from the current client's IP address to the server exceeds the maximum allowed by the server. Generally, 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. |
| 422 | The number of connections from the current client's IP address to the server exceeds the maximum allowed by the server. Generally, 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. |
| 422 | The request format is correct, but it cannot be processed due to 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 a PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Defined in the draft WebDav Advanced Collections, but not in the WebDAV Sequence Set Protocol (RFC 3658). |
| 426 | The client should switch to TLS/1.0. (RFC 2817) |
| 449 | By Microsoft extension, the delegate request should be retried after performing the appropriate action. |
| 500 | The server encountered an unexpected condition that prevented it from completing the request. Generally speaking, this problem will occur when the server's program code is wrong. |
| 501 | The server does not support a feature required by the current request. When the server does not recognize the requested method and cannot support its request for any resource. |
| 502 | A server operating as a gateway or proxy receives an invalid response from an upstream server when attempting to execute a request. |
| 503 | The server is currently unable to process requests due to temporary server maintenance or overload. This situation is temporary and will be restored after a period of time. If the delay time can be expected, the response can include a Retry-After header to indicate the delay time. If this Retry-After information is not given, the client should handle it in the same way as the 500 response. Note: The existence of 503 status code does not mean that the server must use it when overloaded. Some servers simply want to deny clients connections. |
| 504 | When a server acting as a gateway or proxy attempts to fulfill a request, it fails to receive a response in a timely manner from an upstream server (identified by the URI, such as an HTTP, FTP, or LDAP server) or a helper server (such as a DNS server). Note: Some proxy servers will return a 400 or 500 error when a DNS query times out. |
| 505 | The server does not support, or refuses to support, the HTTP version used in the request. This suggests that the server cannot or will not use the same protocol version as the client. The response shall include an entity that describes why the version is not supported and which protocols the server does support. |
| 506 | Extended by the Transparent Content Negotiation Protocol (RFC 2295), the delegate server has an internal configuration error: the requested negotiation argument resource is configured to use itself in transparent content negotiation, and therefore is not an appropriate focus in a negotiation process. |
| 507 | The server could not store the content necessary to complete the request. This situation is considered temporary. WebDAV(RFC 4918) |
| 509 | The server has reached its bandwidth limit. This is not an official status code, but it is still widely used. |
| 510 | The strategies needed to obtain resources are not unmet. (RFC 2774) |
Friend Links:iCMS