Status code meaning
one hundred The client should continue to send requests. This temporary response is used to notify the client that some of its requests have been received by the server and have not been rejected. The client should continue to send the rest of the request, or ignore the response if the request has been completed. The server must send a final response to the client after the request is completed.
one hundred and one The server has understood the client's request and will notify the client to complete the request using a different protocol through the Upgrade header. After sending the last blank line of the response, the server will switch to the protocols defined in the Upgrade header. Similar measures should be taken only when switching to a new protocol is more beneficial. For example, switching to a new HTTP version is more advantageous than the old version, or switching to a real-time and synchronous protocol to transfer resources that take advantage of such features.
one hundred and two The status code extended by WebDAV (RFC 2518) represents that the processing will continue.
two hundred The request has been successful. The response header or data body expected by the request will be returned with this response.
two hundred and one The request has been implemented, and a new resource has been created according to the requirements of the request, and its URI has been returned with the Location header information. If the required resources cannot be created in time, '202 Accepted' should be returned.
two hundred and two The server accepted the request but has not yet processed it. Just as it may be rejected, the request may or may not be executed in the end. In the case of asynchronous operation, there is no more convenient method than sending this status code. The purpose of the response that returns 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 all batch operations are completed. The response receiving request processing and returning 202 status code should include some information indicating the current status of processing in the returned entity, 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.
two hundred and three The server has successfully processed the request, but the returned entity header meta information is not a valid set on the original server, but a copy from the local or a 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 super meta information. It is not necessary to use this status code, and it is only appropriate if the response will return 200 OK without using this status code.
two hundred and four The server successfully processes the request, but does not need to return any entity 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 header information exists, it should correspond to the requested variable. If the client is a browser, the user browser should retain the page that sent the request without any change 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. Since the 204 response is prohibited from containing any message body, it always ends with the first empty line after the message header.
two hundred and five The server successfully processed the request and returned nothing. However, unlike the 204 response, the response that returns this status code requires the requester to reset the document view. This response is mainly used to reset the form immediately after receiving 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.
two hundred and six The server has successfully processed some GET requests. HTTP download tools like FlashGet or Thunderbolt use this type of response to achieve breakpoint resume or to break a large document into multiple download segments for simultaneous download. The request must contain the Range header information to indicate the content range the client wants, and may contain If Range as the request condition. The response must contain the following header fields: Content Range is used to indicate the range of content returned in this response; If the content type is multipart/bytes, each multipart segment should contain the Content Range field to indicate the content range of this segment. If the response contains Content Length, its value must match the actual number of bytes of the content range it returns. Date ETag and/or Content Location, if the same request should return 200 responses. Expires, Cache Control, and/or Vary, if their values may be different from those corresponding to other responses of the same variable before. If the response request uses If Range strong cache verification, the response should not contain other entity headers; If the request in this response uses If Range weak cache verification, then this response must not 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 be returned in the 200 response. If the ETag or Last Modified headers cannot match exactly, the client cache should prohibit combining the contents returned by the 206 response with any previously cached contents. Any cache that does not support Range and Content Range headers prohibits caching the content returned by 206 responses.
two hundred and seven The status code extended by WebDAV (RFC 2518) represents that the following message body will be an XML message, and may contain a series of independent response codes according to the number of previous sub requests.
three hundred The requested resource has a series of feedback information to choose from, each with its own specific address and browser driven consultation information. Users or browsers can choose a preferred address for redirection. Unless this is a HEAD request, the response should include an entity in the list of resource characteristics and addresses so that the user or browser can select the most appropriate redirect address from them. The format of this entity is determined by the format defined by Content Type. The browser may automatically make the most appropriate choice according to the response format and the browser's own capabilities. Of course, the RFC 2616 specification does not specify how such automatic selection should be carried out. If the server itself has a preferred feedback selection, the URI of this feedback should be specified in Location; The browser may use this Location value as the address for automatic redirection. In addition, unless otherwise specified, this response is also cacheable.
three hundred and one The requested resource has been permanently moved to a new location, and any future reference to this resource should use one of the several URIs returned by this response. If possible, the client with link editing function should automatically change the requested address to the one fed back from the server. Unless otherwise specified, this response is also cacheable. The new persistent 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, because the request conditions may change accordingly. Note: For some browsers that use the HTTP/1.0 protocol, when the POST request they send gets a 301 response, the next redirect request will become GET.
three hundred and two The requested resource now responds to the request temporarily from a different URI. Since such redirection is temporary, the client should continue to send future requests to the original address. This response is cacheable only when 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 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, because the request conditions may change as a result. Note: Although RFC 1945 and RFC 2068 do not allow the client to change the request method when redirecting, many existing browsers regard the 302 response as a 303 response, and use GET to access the URI specified in Location, ignoring the original request method. The status codes 303 and 307 have been added to clarify how the server expects the client to react.
three hundred and three The response corresponding to the current request can be found on another URI, and the client should use GET to access that resource. This method exists mainly to allow the output of POST requests activated by scripts 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 are 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 responding entity should contain a hyperlink to the new URI and a short description. Note: Many browsers before HTTP/1.1 cannot correctly understand 303 status. If interaction with these browsers needs to be considered, 302 status codes should be competent, because the way most browsers process 302 responses is exactly what the above specification requires clients to do when processing 303 responses.
three hundred and four If the client sends a GET request with conditions and the request is allowed, but the content of the document (since the last access or according to the conditions of the request) has not changed, the server should return this status code. 304 The response must not contain the message body, so 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 clock also follows these rules, the proxy server and 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 200 responses. Expires, Cache Control, and/or Vary, if their values may be different from those corresponding to other responses of the same variable before. If this response request uses strong cache verification, then this response should not contain other entity headers; Otherwise (for example, a conditional GET request uses weak cache verification), this response must not contain other entity headers; This avoids inconsistency between cached entity content and updated entity header information. If a 304 response indicates that an entity is not cached, the caching system must ignore the response and repeatedly send requests that do not contain restrictions. If a 304 response is received to update a cache entry, the cache system must update the entire entry to reflect the values of all fields updated in the response.
three hundred and five The requested resource can only be accessed through the specified proxy. The URI information of the specified proxy will be given in the Location field, and the receiver needs to repeatedly send a separate request, through which the corresponding resource can be accessed. Only the original server can establish a 305 response. Note: RFC 2068 does not specify that the 305 response is to redirect a separate request and can only be established by the original server. Ignoring these restrictions may lead to serious safety consequences.
three hundred and six In the latest version of the specification, 306 status code is no longer used.
three hundred and seven The requested resource now responds to the request temporarily from a different URI. Since such redirection is temporary, the client should continue to send future requests to the original address. This response is cacheable only when 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 responding entity should contain a hyperlink to the new URI and a short description. Because some browsers cannot recognize the 307 response, the above necessary information needs to be added so that users can understand and send access requests to the new URI. If this is not a GET or HEAD request, the browser prohibits automatic redirection unless confirmed by the user, because the request conditions may change as a result.
four hundred 1. Semantic error. The current request cannot be understood by the server. Unless modified, the client should not submit this request repeatedly. 2. The request parameters are incorrect.
four hundred and one The current request requires user authentication. The response must contain a WWW Authenticate header for the requested resource to query the user information. The client can repeatedly submit a request containing the appropriate Authorization header information. If the current request already contains the Authorization certificate, the 401 response represents that the server has rejected those certificates. If the 401 response contains the same authentication query as the previous response, and the browser has tried authentication at least once, the browser should show the user the entity information contained in the response, because the entity information may contain relevant diagnostic information. See RFC 2617.
four hundred and two This status code is reserved for possible future requirements.
four hundred and three The server understood the request, but refused to execute it. Unlike 401 responses, authentication does not provide any 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 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.
four hundred and four The request failed. The resource that the request wanted 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 tell the old resource that it is permanently unavailable due to some internal configuration mechanism problems, and there is no address to jump to. The status code 404 is widely used when the server does not want to reveal why the request was rejected or no other suitable response is available.
four hundred and five The request method specified in the request line cannot be used to request the corresponding resource. The response must return an Allow header to indicate the list of request methods that the current resource can accept. Because PUT and DELETE methods will write to the resources on the server, most web servers do not support or do not allow the above request methods in the default configuration, and 405 errors will be returned for such requests.
four hundred and six The content characteristics of the requested resource cannot meet 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 the most appropriate entity feature and address list from which the user or browser can select. 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.
four hundred and seven Similar to the 401 response, except that the client must authenticate on the proxy server. The proxy server must return a Proxy Authenticate for identity inquiry. The client can return a Proxy Authorization header for verification. See RFC 2617.
four hundred and eight The request timed out. The client did not complete sending a request within the server's waiting time. The client can submit this request again at any time without making any changes.
four hundred and nine The request could not be completed because of a conflict with the current state of the requested resource. This code can only be used when the user is considered to be able to resolve the conflict and resubmit a new request. The response should contain enough information for the user to find the source of the conflict. Conflicts usually occur in the processing of PUT requests. For example, in the context of version checking, if the version information attached to a PUT submitted modification request for a specific resource conflicts with a previous (third-party) request, the server should return a 409 error to inform the user that the request cannot be completed. At this time, the response entity is likely to include the difference comparison between the two conflicting versions, so that the user can resubmit the merged new version.
four hundred and ten 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 link editing function should delete all references to this address after obtaining user 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. 410 The purpose of the response is to help the website administrator maintain the website, notify the user that the resource is no longer available, and the server owner hopes that all remote connections to the resource will also be deleted. Such events are common in time limited and value-added services. Similarly, the 410 response is also used to notify the client that the resources originally belonging to an individual are no longer available on the current server site. Of course, whether you need to mark all permanently unavailable resources as' 410 Gone 'and whether you need to keep this mark for a long time depends entirely on the server owner.
four hundred and eleven The server refused to accept the request without defining a Content Length header. After adding a valid Content Length header indicating the length of the request message body, the client can submit the request again.
four hundred and twelve The server failed to meet one or more of the prerequisites given in the request header field during verification. This status code allows the client to set preconditions in the requested meta information (request header field data) when acquiring resources, so as to avoid the request method being applied to resources other than the content it wants.
four hundred and thirteen 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 the request. If this condition is temporary, the server should return a Retry After response header to tell the client how long it can retry.
four hundred and fourteen The requested URI length exceeds the length that the server can interpret, so the server refused to service the request. This is relatively rare. Common situations include that the form submission that should have used the POST method has changed to the GET method, resulting in an excessively long query string. Redirect the URI "black hole". For example, each redirect uses the old URI as part of the new URI, resulting in the super long URI after several times of retargeting. The client is trying to exploit the security vulnerabilities in some servers to attack the server. This type of server uses a fixed length buffer to read or operate the requested URI. When the parameter after GET exceeds a certain value, a buffer overflow may occur, causing arbitrary code to be executed [1]. The server without such vulnerability should return 414 status code.
four hundred and fifteen For the currently requested method and requested resource, the entity submitted in the request is not in the format supported by the server, so the request is rejected.
four hundred and sixteen If the request contains a Range request header, and any data range specified in the Range does not coincide with the available range of the current resource, and if the If Range request header is not defined in the request, the server should return a 416 status code. If Range uses a byte range, this means that the first byte position of all data ranges specified in the request exceeds the length of the current resource. The server should also include a Content Range entity header to indicate the length of the current resource while returning a 416 status code. This response is also prohibited from using multipart/byteranges as its Content Type.
four hundred and seventeen The expected content specified in the request header Expect cannot be met by the server, or the server is a proxy server, which has obvious evidence to prove that the expected content cannot be met on the next node of the current route.
four hundred and twenty-one The number of connections from the IP address of the current client to the server exceeds the maximum range of server licenses. 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.
four hundred and twenty-two The number of connections from the IP address of the current client to the server exceeds the maximum range of server licenses. 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.
four hundred and twenty-two The request format is correct, but it cannot respond due to semantic errors. (RFC 4918 WebDAV) 423 Locked The current resource is locked. (RFC 4918 WebDAV)
four hundred and twenty-four The current request fails due to an error in a previous request, such as PROPPATCH. (RFC 4918 WebDAV)
four hundred and twenty-five It is defined in the draft of WebDav Advanced Collections, but does not appear in the WebDAV Sequential Set Protocol (RFC 3658).
four hundred and twenty-six The client should switch to TLS/1.0. (RFC 2817)
four hundred and forty-nine Extended by Microsoft, the representative request should be retried after performing appropriate operations.
five hundred The server encountered an unexpected condition that prevented it from processing the request. Generally speaking, this problem occurs when the program code of the server fails.
five hundred and one 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.
five hundred and two When the server working as a gateway or proxy tried to execute the request, it received an invalid response from the upstream server.
five hundred and three The server is currently unable to process requests due to temporary server maintenance or overload. This condition is temporary and will be recovered in a period of time. If the delay time can be predicted, the response can include a Retry After header to indicate the delay time. If the Retry After information is not given, the client should process the 500 response. Note: The existence of the 503 status code does not mean that the server must use it when it is overloaded. Some servers simply want to deny client connections.
five hundred and four When the server working as a gateway or proxy attempts to execute the request, it fails to receive a response from the upstream server (the server identified by the URI, such as HTTP, FTP, LDAP) or the secondary server (such as DNS) in a timely manner. Note: Some proxy servers will return 400 or 500 errors when DNS query timeout occurs
five hundred and five 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 include an entity that describes why the version is not supported and which protocols the server supports.
five hundred and six Extended by the Transparent Content Negotiation Protocol (RFC 2295), it indicates that the server has an internal configuration error: the requested negotiation argument resource is configured to use itself in transparent content negotiation, so it is not an appropriate focus in a negotiation process.
five hundred and seven The server cannot store the content necessary to complete the request. This situation is considered temporary. WebDAV (RFC 4918)
five hundred and nine The server has reached the bandwidth limit. This is not an official status code, but it is still widely used.
five hundred and ten The strategy needed to obtain resources is not unsatisfied. (RFC 2774)