Tips: Ctrl+F Quick Find
| Http status code | Status Code Meaning |
|---|---|
| 100 | The client should continue sending requests. This provisional response is used to inform the client that part of its request has been accepted 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 has already been completed. The server MUST send a final response to the client after the request has been completed. |
| 101 | The server has understood the client's request, and will notify the client to use a different protocol to complete the request through the Upgrade message header. After sending the last blank line of this response, the server will switch to those protocols defined in the Upgrade header. Similar measures should only be taken when switching to a new protocol would be beneficial. For example, switching to a new HTTP version that has advantages over older versions, or switching to a real-time and synchronous protocol to deliver resources that take advantage of 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 expected 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 request, and its URI has been returned with the Location header information. If the required resource cannot be created in time, a '202 Accepted' should be returned. |
| 202 | The server has 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 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-based operation that is performed only once a day) without having the client stay connected to the server until the batch operation is complete. Responses that accept request processing and return a 202 status code SHOULD include in the returned entity some information indicating the current state of the processing, as well as a pointer to a processing status monitor or status forecast, so that the user can estimate whether the operation has completed. |
| 203 | The server has successfully processed the request, but the entity header meta-information returned is not a definite set valid on the original server, but a copy from the local or a third party. Current information may be a subset or superset of the original version. For example, including a resource's metadata might lead to a super where the origin server knows the metadata. Using this status code is not required, and is only appropriate if the response would return 200 OK without 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. Responses may return new or updated meta information in the form of entity headers. These headers, if present, should correspond to the requested variables. If the client is a browser, then the user's browser should retain the page that sent the request without any changes to the document view, even though new or updated meta information should be applied to the user's browser activity according to the specification Documentation in view. Since a 204 response is forbidden to contain any message body, it always ends with the first empty line after the headers. |
| 205 | The server successfully processed the request and returned nothing. But 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 the 204 response, this response is also forbidden to contain any message body, and ends with the first blank line after the message header. |
| 206 | The server has successfully processed some GET requests. HTTP download tools like FlashGet or Xunlei use this type of response to resume downloads or break down a large file into multiple download segments for simultaneous download. The request must contain Range header information to indicate the content range that the client expects, and may contain If-Range as a request condition. The response must contain the following header fields: Content-Range is used to indicate the range of the content returned in this response; if it is a multi-part download with Content-Type as multipart/byteranges, each multipart part should contain Content-Range Domains are used to indicate the content scope of this paragraph. If a Content-Length is included in the response, its value MUST match the actual number of bytes it returns for the 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 previous responses for the same variable. 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 including other entity headers; this avoids The inconsistency between the cached entity content and the updated entity header information is resolved. Otherwise, this response should contain all entity header fields that should be returned in a 200 response. If the ETag or Last-Modified header cannot be matched exactly, the client cache should prohibit combining the content returned by the 206 response 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 extended by WebDAV (RFC 2518), which means that the subsequent message body will be an XML message, and may contain a series of independent response codes according to the number of previous sub-requests. |
| 300 | The resource being requested has a range of alternative return 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 properties and addresses from which the user or browser can choose the most appropriate redirection address. The format of this entity is determined by the format defined by the Content-Type. The browser may automatically make the most appropriate choice 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 be performed. If the server itself has a preferred feedback option, the URI of the feedback should be specified in the Location; the browser may use this Location value as the address for automatic redirection. Additionally, 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 several URIs returned by this response. Clients with link editing capabilities should automatically change the requested address to the one returned from the server, if possible. 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 body of the response should contain a hyperlink to the new URI and a short description. If this is not a GET or HEAD request, the browser forbids automatic redirection unless confirmed by the user, since the conditions of the request may change accordingly. Note: For some browsers using the HTTP/1.0 protocol, when the POST request they send gets a 301 response, the subsequent redirection request will become a GET method. |
| 302 | The requested resource is now temporarily responding to requests from a different URI. Since such redirection is temporary, the client SHOULD continue to send future requests to the original address. The 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 body of the response should contain a hyperlink to the new URI and a short description. 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 accordingly. Note: Although the RFC 1945 and RFC 2068 specifications do not allow the client to change the method of the request when redirecting, many existing browsers regard the 302 response as a 303 response, and use the GET method to access the URI specified in the Location, regardless of The originally requested method. Status codes 303 and 307 were added to specify 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 use a GET to access that resource. This method exists primarily to allow the output of a script-activated POST request to be redirected to a new resource. This new URI is not a substitute reference to the original resource. At the same time, 303 responses must not be cached. Of course, the second request (redirect) might be cached. The new URI should be returned in the Location field of the response. Unless this is a HEAD request, the body of the response should contain a hyperlink to the new URI and a short description. Note: Many pre-HTTP/1.1 browsers do not understand the 303 status correctly. If you need to consider the interaction with these browsers, the 302 status code should be competent, because the way most browsers handle 302 responses is exactly what the above specification requires clients to do when handling 303 responses. |
| 304 | The server SHOULD return this status code if the client sends a conditional GET request and the request is allowed, but the content of the document has not changed (since the last access or according to the requested conditions). A 304 response is forbidden to include a message body, so it always ends with the first empty line after the headers. The response MUST contain the following header: 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 by themselves (as specified in RFC 2068), and the caching mechanism will work normally. ETag and/or Content-Location, if the same request would have returned a 200 response. Expires, Cache-Control, and/or Vary, if their values may differ from previous responses for 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 is prohibited from including other entity headers; this avoids Fixes inconsistencies between cached entity content and updated entity headers. If a 304 response indicates that an entity is not currently cached, the caching system MUST ignore the response and repeat the request without constraints. If a 304 response is received requesting an update of a cache entry, the caching system MUST update the entire entry to reflect the values of all fields that were updated in the response. |
| 305 | The requested resource must be accessed through the specified proxy. The Location field will give the URI information of the specified proxy, and the receiver needs to repeatedly send a separate request to access the corresponding resource through this proxy. Only origin servers can build 305 responses. Note: It is not clear in RFC 2068 that the 305 response is intended to redirect a single request and can only be created by the origin server. Ignoring these restrictions can have serious security consequences. |
| 306 | In the latest version of the specification, the 306 status code is no longer used. |
| 307 | The requested resource is now temporarily responding to requests from a different URI. Since such redirection is temporary, the client SHOULD continue to send future requests to the original address. The 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 body of the response should contain a hyperlink to the new URI and a short description. Because some browsers cannot recognize the 307 response, it is necessary to add the above-mentioned necessary information so that the user can understand and send an access request 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 accordingly. |
| 400 | 1. The semantics are wrong, and the current request cannot be understood by the server. Clients SHOULD NOT resubmit this request unless modified. 2. The request parameter is wrong. |
| 401 | The current request requires user authentication. The response MUST include a WWW-Authenticate header applicable to the requested resource to ask for user information. The client MAY resubmit a request with the appropriate Authorization header. If the current request already contains the Authorization certificate, then the 401 response means that the server verification has rejected those certificates. 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 display the entity information contained in the response to the user, because this entity information may contain relevant diagnostic information . See RFC 2617. |
| 402 | This status code is reserved for possible future needs. |
| 403 | The server has understood the request, but is refusing to honor it. Unlike a 401 response, authentication doesn't help, and the request shouldn't be repeated. 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. There is no information to tell the user whether the condition is temporary or permanent. If the server knows the situation, it should use the 410 status code to inform that the old resource is permanently unavailable due to some internal configuration mechanism problems, and 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 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 the current resource can accept. Since the PUT and DELETE methods will write to the resources on the server, most of the web servers do not support or do not allow the above request methods under the default configuration, and a 405 error will be returned for such requests. |
| 406 | The content characteristics of the requested resource cannot satisfy the conditions in the request header, so 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 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 its own best choice according to the format and its own capabilities. However, the specification does not define any criteria for making such an automatic selection. |
| 407 | Similar to a 401 response, except that the client must be authenticated on the proxy server. The proxy server must return a Proxy-Authenticate for identity query. The client can return a Proxy-Authorization header for authentication. See RFC 2617. |
| 408 | The request timed out. 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 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 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 during the processing of PUT requests. For example, in an environment where version checking is used, if the version information attached to a modification request for a specific resource submitted by a PUT conflicts with a previous (third-party) request, then the server should return a 409 error at this time. Inform the user that the request cannot be completed. At this point, the response entity is likely to contain a difference comparison 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 does not have any known forwarding addresses. Such a condition should be considered permanent. If possible, clients with link editing capabilities should remove all references to this address after obtaining 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 specified, this response is cacheable. The purpose of the 410 response is mainly to help website administrators maintain the website, inform users that the resource is no longer available, and the server owner wants all remote connections to this resource to be deleted. Such events are common in time-limited, value-added services. Similarly, the 410 response is also used to inform the client that resources originally belonging to an individual are no longer available on the current server site. Of course, it is entirely up to the server owner whether to mark all permanently unavailable resources as '410 Gone' and for how long. |
| 411 | The server refuses to accept the request without a Content-Length header defined. The client MAY resubmit the request after adding a valid Content-Length header indicating the length of the request body. |
| 412 | The server failed to satisfy one or more of the prerequisites given in the request's header fields while validating. This status code allows the client to set preconditions in the meta information (request header field data) of the request when obtaining resources, so as to prevent the request method from being applied to resources other than the content it expects. |
| 413 | The server refuses to process the current request because the size of the entity data submitted by the request exceeds the range that 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 this request. If the condition is temporary, the server SHOULD return a Retry-After response header to tell the client how much time later to try again. |
| 414 | The requested URI is longer than the server can interpret, so the server refuses to service the request. This is relatively rare, and the usual situation includes: the form submission that should have used the POST method has become a GET method, resulting in a query string (Query String) that is too long. Redirection URI "black holes", for example, each redirection uses the old URI as part of the new URI, resulting in a URI that is too long after several redirections. The client is trying to attack the server by exploiting a security hole in some server. This type of server uses a fixed-length buffer to read or operate the requested URI. When the parameters after GET exceed a certain value, a buffer overflow may occur, causing arbitrary code to be executed [1]. Servers without such vulnerabilities should return a 414 status code. |
| 415 | For 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. |
| 416 | If the request contains a Range request header, and any data range specified in Range does not coincide with the available range of the current resource, and the request does not define an If-Range request header, then the server should return a 416 status code . If Range uses a byte range, then this situation means that the first byte position of all data ranges specified by the request exceeds the length of the current resource. The server should also include a Content-Range entity header to indicate the length of the current resource while returning 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 satisfied by the server, or the server is a proxy server, which has obvious evidence that the content of Expect cannot be satisfied on the next node of the current route. |
| 421 | The number of connections to the server from the current IP address of the client exceeds the maximum range allowed 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. |
| 422 | The number of connections to the server from the current IP address of the client exceeds the maximum range allowed 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. |
| 422 | The request is well-formed, but could not be responded because it contained a semantic error. (RFC 4918 WebDAV) 423 Locked The current resource is locked. (RFC 4918 WebDAV) |
| 424 | The current request failed due to an error in a previous request, such as PROPPATCH. (RFC 4918 WebDAV) |
| 425 | is defined in the WebDav Advanced Collections draft, but does not appear in the "WebDAV Sequenced Collections Protocol" (RFC 3658). |
| 426 | Clients should switch to TLS/1.0. (RFC 2817) |
| 449 | is extended by Microsoft to indicate that the request should be retried after performing the appropriate action. |
| 500 | The server encountered an unexpected condition that prevented it from completing processing the request. Generally speaking, this problem will appear when the program code of the server 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 working as a gateway or proxy received an invalid response from an upstream server while attempting to fulfill the request. |
| 503 | The server is currently unable to process the request due to temporary server maintenance or overloading. This condition is temporary and will recover over time. If the delay time can be estimated, the response can include a Retry-After header to indicate the delay time. If this Retry-After message is not given, then the client SHOULD handle it in the same way as a 500 response. Note: The existence of a 503 status code does not mean that the server must use it when it is overloaded. Some servers simply wish to reject connections from clients. |
| 504 | A server acting as a gateway or proxy failed to receive a timely response from an upstream server (the server identified by the URI, such as HTTP, FTP, LDAP) or a secondary server (such as DNS) when attempting to fulfill the request. Note: Some proxy servers will return 400 or 500 errors when the DNS query times out |
| 505 | The server does not support, or refuses to support, the HTTP version used in the request. This implies that the server cannot or will not 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. |
| 506 | is extended by the "Transparent Content Negotiation Protocol" (RFC 2295), which means that the server has an internal configuration error: the requested negotiation variable resource is configured to use itself in transparent content negotiation, so it is not a suitable one in a negotiation process the key of. |
| 507 | The server cannot store the content necessary to fulfill the request. This condition is considered temporary. WebDAV (RFC 4918) |
| 509 | Server reached bandwidth limit. This is not an official status code, but is still widely used. |
| 510 | The strategy required to acquire the resource is not satisfied. (RFC 2774) |
Popular tools：