http status code function

The function of HTTP status code is: the web server is used to tell the client what happened.

The status code is located in the first line of the HTTP Response and will return a "three-digit status code" and a "status message". The "three-digit status code" is easier for the program to process, and the "status message" is easier for people to understand.

Status code classification

HTTP status codes are divided into five major categories. The current HTTP protocol version we use is 1.1, and the following status codes are supported. As the protocol develops, more status codes will be defined in the HTTP specification.

Tips: If you see a status code 518, you don’t know what 518 specifically means. At this time, you only need to know that 518 belongs to (5XX, server error is enough)

Defined range Category

1XX 100-101 Information prompt

2XX 200-206 Success

3XX 300-305 Repeat Orientation

4XX 400 -415 Client Error

5XX 500-505 Server Error

Common status codes

Most people only need to understand the following common status codes. If you want to know more, please continue reading.

200 OK The server successfully processed the request (this is what we see most)

301/302 Moved Permanently (Redirect) The requested URL has been moved. The Response should contain a Location URL, indicating the current location of the resource.

304 Not Modified (Unmodified) The client's cached resource is the latest, requiring the client to use the cache.

404 Not Found. The resource was not found.

501 Internal Server ErrorThe server encountered an error that prevented it from serving the request.

1xx message

This type of status code means that the request has been accepted and needs to continue processing. This type of response is a temporary response, containing only a status line and some optional response header information, and ending with a blank line. Since no 1xx status codes are defined in the HTTP/1.0 protocol, servers are prohibited from sending 1xx responses to such clients except under certain experimental conditions. The responses represented by these status codes are informational and indicate additional actions that the client should take.

100 Continue The client should continue sending requests. This provisional 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 sending the remainder of the request, or ignore this response if the request has already been completed. The server must send a final response to the client after the request is completed. 101 Switching Protocols (switching protocol) The server has understood the client's request and will notify the client through 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 the protocols defined in the Upgrade header. Such measures should only be taken when switching to a new protocol is more beneficial. For example, switching to a new HTTP version has advantages over an older version, or switching to a real-time and synchronous protocol for delivering resources that take advantage of such features. 102 Processing is a status code extended by WebDAV (RFC 2518), indicating that processing will continue.

2xx Success

This type of status code means that the request has been successfully received, understood, and accepted by the server.

200 OK (Success) The request has been successful, and the response header or data body expected by the request will be returned with this response. 201 Created (created) request has been implemented, and a new resource has been created according to the request's needs, 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. 202 Accepted The server has accepted the request but has not yet processed it. Just as it may be denied, the request may or may not ultimately 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 only performed once a day) without having to keep the client connected to the server until the batch operation is completed. A response that accepts request processing and returns a 202 status code should contain some information in the returned entity indicating the current status of the processing, as well as a pointer to a processing status monitor or status prediction so that the user can estimate whether the operation has been completed. 203 Non-Authoritative Information (non-authorized information) The server has successfully processed the request, but the entity header metainformation returned is not a determined set that is 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, containing metadata for a resource may result in the origin server knowing a superset of the metainformation. Using this status code is not required and is only appropriate if the response would have returned 200 OK without this status code. 204 No Content The server successfully processed 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 metainformation in the form of entity headers. These headers, if present, should correspond to the requested variables. If the client is a browser, the user's browser SHOULD retain the page for which the request was made without any changes to the document view, even if new or updated metainformation should be applied to the user's browser activity according to the specification Document in view. Since a 204 response is prohibited from containing any message body, it always ends with the first empty line after the message header. 205 Reset Content The server successfully processed the request and returned no content. 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 prohibited from containing any message body and ends with the first blank line after the message header. 206 Partial Content (Partial Content) The server has successfully processed a partial GET request. HTTP download tools such as FlashGet or Thunder use this type of response to implement breakpoint resuming or to break a large document into multiple download segments for simultaneous downloading. The request must include a Range header to indicate the range of content the client expects, and may include an If-Range as a 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 it is a multi-part download with Content-Type multipart/byteranges, each multipart part contains The Content-Range field should be included to indicate the content range of this paragraph. If a Content-Length is included in the response, its value must match the actual number of bytes in the content range it returns.

Date

ETag and/or Content-Location, if the same request should have returned a 200 response.

Expires, Cache-Control, and/or Vary, if 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 this response request uses If-Range weak cache verification, then this response is prohibited from containing other entity headers; This avoids inconsistencies between cached entity content and updated entity header information. Otherwise, this response should contain all entity header fields that should be returned in a 200 response. If the ETag or Last-Modified headers do not match exactly, the client cache should not combine the content returned by the 206 response with any previously cached content. Any cache that does not support Range and Content-Range headers is prohibited from caching content returned by a 206 response. 207 Multi-Status is a 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 depending on the number of previous sub-requests.

3xx redirect

This type of status code means that the client needs to take further action to complete the request. Usually, these status codes are used for redirection, and the subsequent request address (redirect target) is specified in the Location field of this response.

If and only if the method used in subsequent requests is GET or HEAD, the user's browser can automatically submit the required subsequent requests without user intervention. Clients should automatically detect infinite loop redirects (for example: A→B→C→...→A or A→A), because this will cause a lot of unnecessary resource consumption on the server and client. As recommended by the HTTP/1.0 specification, browsers should not automatically access more than 5 redirects.

300 Multiple Choices The requested resource has a range of alternative responses, 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 attributes and addresses from which the user or browser can choose the most appropriate redirect address. The format of this entity is determined by the format defined by Content-Type. The browser may automatically make the most appropriate choice based on the 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 already has a preferred feedback choice, the URI of this feedback should be specified in Location; the browser may use this Location value as the address for automatic redirection. Additionally, this response is cacheable unless otherwise specified. 301 Moved Permanently 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 in this response. If possible, clients with link editing capabilities should automatically modify the requested address to the address returned 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 response entity should contain a hyperlink to the new URI and a brief description. If this is not a GET or HEAD request, the browser prohibits automatic redirection unless confirmed by the user, because the conditions of the request 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 subsequent redirect request will become a GET method. 302 Found (Temporarily Moved) The requested resource is now temporarily served from a different URI. Because such redirects are temporary, the client should continue to send future requests to the original address. This 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 response entity should contain a hyperlink to the new URI and a brief description. If this is not a GET or HEAD request, 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 request method 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 method of the original request. Status codes 303 and 307 were added to clarify what response the server expects from the client. 303 See Other The response to the current request can be found at another URI, and the client should use GET to access that resource. This method exists primarily to allow script-activated POST request output to be redirected to a new resource. This new URI is not a replacement reference to the original resource. At the same time, 303 responses are prohibited from being 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 response entity should contain a hyperlink to the new URI and a brief description. Note: Many pre-HTTP/1.1 browsers do not correctly understand the 303 status. If you need to consider interaction with these browsers, the 302 status code should be sufficient, because most browsers handle 302 responses exactly the way the above specification requires the client to handle 303 responses. 304 Not Modified (not modified) 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 conditions of the request), the server should return this status code. A 304 response is prohibited from including a message body, so it always ends with the first blank line after the message header. The response must contain the following header information:

Date, unless the server does not have a clock. If servers without clocks also comply with these rules, then proxy servers and clients can add the Date field to the received response headers themselves (as specified in RFC 2068), and the caching mechanism will work normally.

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 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 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 that requires an update to a cache entry, the cache system must update the entire entry to reflect the values ​​of all fields that were updated in the response. 305 Use Proxy The requested resource must be accessed through the specified proxy. The URI information of the specified proxy will be given in the Location field. The recipient needs to repeatedly send a separate request to access the corresponding resources through this proxy. Only the origin 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 created by the origin server. Ignoring these restrictions can lead to serious safety consequences. 306 Switch Proxy In the latest version of the specification, the 306 status code is no longer used. 307 Temporary Redirect The requested resource now temporarily responds to requests from a different URI. Because such redirects are temporary, the client should continue to send future requests to the original address. This 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 response entity should contain a hyperlink to the new URI and a brief description. Because some browsers cannot recognize the 307 response, the above necessary information needs to be added so that users can understand and make 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 conditions of the request may change accordingly.

4xx Client Error

This type of status code means that an error may have occurred on the client, which is hindering the server's processing. Unless the response is a HEAD request, the server SHOULD return an entity explaining the current error condition and whether it is temporary or permanent. These status codes apply to any request method. Browsers should display any entity content contained in such error responses to the user.

If the client is transmitting data when the error occurs, server implementations using TCP should carefully ensure that the client has received the packet containing the error information before closing the connection between the client and the server. If the client continues to send data to the server after receiving the error message, the server's TCP stack will send a reset packet to the client to clear all the client's unrecognized input buffers to prevent these data from being used by the server. The application reads and interferes with the latter.

400 Bad Request (Bad Request) The current request cannot be understood by the server because it contains syntax errors. The client should not resubmit this request unless modified. 401 Unauthorized (Unauthorized) The current request requires user authentication. The response MUST include a WWW-Authenticate header appropriate to the requested resource that asks for user 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 verification has rejected those certificates. If the 401 response contains the same authentication query 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 Payment Required This status code is reserved for possible future requirements. 403 Forbidden The server understood the request but refused to execute it. Unlike a 401 response, authentication does not provide any help, and the request should not be resubmitted. 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 obtain any information. 404 Not Found (Not Found) The request failed and the resource requested 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 jump address. 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 Method Not Allowed (Method disabled) The request method specified in the request line cannot be used to request the corresponding resource. The response must return an Allow header information to indicate the list of request methods that the current resource can accept. Since the PUT and DELETE methods will write resources on the server, most 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 Not Acceptable (Not Acceptable) 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 attributes 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 based on the format and its capabilities. However, the specification does not define any criteria for making such automatic selections. 407 Proxy Authentication Required is similar to the 401 response, except that the client must authenticate with the proxy server. The proxy server must return a Proxy-Authenticate for identity query. The client can return a Proxy-Authorization header for verification. See RFC 2617. 408 Request Timeout Request timeout. 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 Conflict The request cannot be completed due to a conflict with the current state of the requested resource. This code should only be used if the user is believed 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 usually occur in the processing of PUT requests. For example, in an environment using version checking, 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 time, the response entity is likely to contain a difference comparison between the two conflicting versions, so that the user can resubmit the new version after merging. 410 Gone (Deleted) The requested resource is no longer available on the server and does not have any known forwarding address. Such a situation 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 the condition is permanent, then the 404 status code should be used. Unless otherwise noted, this response is cacheable. The purpose of the 410 response is mainly to help website administrators maintain the website, notify users that the resource is no longer available, and the server owner wants all remote connections pointing to this resource to be deleted. This type of incident is common among limited-time, value-added services. Similarly, the 410 response is also used to notify the client that resources originally belonging to an individual are no longer available on the current server site.Of course, it's entirely up to the server owner whether all permanently unavailable resources need to be marked '410 Gone', and how long they need to keep this mark. 411 Length Required (valid length required) The server refuses to accept the request without defining the 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. 412 Precondition Failed The server failed to satisfy one or more of the preconditions given in the header fields of the request when validating them. This status code allows the client to set preconditions in the request metainformation (request header field data) when retrieving the resource, thereby preventing the request method from being applied to the resource other than what it expects. 413 Request Entity Too Large (Request Entity Too Large) 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 handle. In this case, the server can close the connection to prevent the client from continuing to send this request. If the situation is temporary, the server should return a Retry-After response header to inform the client how long it can try again. 414 Request-URI Too Long (The requested URI is too long) The length of the requested URI exceeds the length that the server can interpret, so the server refuses to serve the request. This is relatively rare. Common situations include:

The form submission that should have used the POST method becomes the GET method, causing the query string to be too long.

Redirect URI "black hole", for example, each redirection uses the old URI as part of the new URI, resulting in an overlong URI after several redirections.

Clients are trying to attack servers by exploiting security vulnerabilities that exist in some servers. 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 Unsupported Media Type (Unsupported Media Type) For the current requested method and requested resource, the entity submitted in the request is not in a format supported by the server, so the request is rejected. 416 Requested Range Not Satisfiable (The requested range does not meet the requirements) If the request contains the Range request header, and 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 , 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 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 the 416 status code. This response is also prohibited from using multipart/byteranges as its Content-Type. 417 Expectation Failed (expectation not met) The expected content specified in the request header Expect cannot be met by the server, or the server is a proxy server and it has obvious evidence that the content of Expect cannot be met on the next node of the current route. satisfy. 418 I'm a teapot This opcode was defined in RFC 2324 Hypertext Coffee Pot Control Protocol as a traditional April Fool's Day joke by the IETF in 1998 and does not need to be defined in a real HTTP server. 421 There are too many connections from your internet address The number of connections from the IP address of the current client to the server 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 connection count may involve more than one end user. 422 Unprocessable Entity The request format is correct, but it cannot respond due to semantic errors. (RFC 4918 WebDAV) 423 LockedThe current resource is locked. (RFC 4918 WebDAV) 424 Failed Dependency The current request failed due to an error in a previous request, such as PROPPATCH. (RFC 4918 WebDAV) 425 Unordered Collection is defined in the WebDav Advanced Collections draft, but does not appear in the "WebDAV Sequential Collection Protocol" (RFC 3658). 426 Upgrade Required Client should switch to TLS/1.0. (RFC 2817) 449 Retry With was extended by Microsoft and indicates that the request should be retried after performing appropriate operations.

5xx Server Error

This type of status code represents that the server has an error or abnormal state while processing the request. It may also be that the server realizes that it cannot complete the processing of the request with the current software and hardware resources. Unless this is a HEAD request, the server SHOULD include an explanation of the current error status and whether the condition is temporary or permanent. The browser SHOULD display any entities included in the current response to the user.

These status codes apply to any response method.

500 Internal Server Error (Server Internal Error) The server encountered an unexpected condition that prevented it from completing the processing of the request. Generally speaking, this problem will occur when there is an error in the server's program code. 501 Not Implemented (not yet implemented) 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 Bad Gateway A server working as a gateway or proxy received an invalid response from the upstream server when trying to perform a request. 503 Service Unavailable (Service Unavailable) Due to temporary server maintenance or overload, the server is currently unable to process the request. This condition 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 message is not given, the client SHOULD handle it the same way it handles a 500 response. 504 Gateway Timeout (Gateway Timeout) When a server working as a gateway or proxy tries to execute a request, it fails to receive a response in time from the upstream server (the server identified by the URI, such as HTTP, FTP, LDAP) or the auxiliary server (such as DNS). Note: Some proxy servers will return a 400 or 500 error when a DNS query times out. 505 HTTP Version Not Supported The server does not support, or refuses to support, the HTTP version 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 describing why the version is not supported and what protocols the server supports. 506 Variant Also Negotiates is extended by the Transparent Content Negotiation Protocol (RFC 2295) and represents an internal configuration error in the server: the requested negotiation variable resource is configured to use itself in transparent content negotiation, and therefore is not a negotiation process. Appropriate focus. 507 Insufficient Storage The server cannot store the content necessary to complete the request. This condition is considered temporary. (WebDAV RFC 4918) 509 Bandwidth Limit Exceeded The server has reached its bandwidth limit. This is not an official status code, but is still widely used. 510 Not Extended The policy required to obtain the resource is not met. (RFC 2774)