HTTP status Code detailed

HTTP Status code detailed

Status code	Meaning
100	The client should continue to send the request. This temporary response is used to inform the client that some of its requests have been received by the server and are still not rejected. The client should continue to send the remainder 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 complete.
101	The server has understood the client's request and will notify the client via a upgrade message header that a different protocol is being used to complete the request. After the last empty line of the response is sent, the server switches to those protocols defined in the upgrade message 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 an older version, or switching to a real-time, synchronized protocol to deliver resources that exploit this type of feature.
102	The status code that is extended by WebDAV (RFC 2518), on behalf of processing, will continue to execute.
200	The request was successful, and the desired response header or data body will be returned with this response.
201	The request has been implemented, and a new resource has been established according to the request, and its URI has been returned with the location header information. If the necessary resources cannot be established in time, the ' 202 Accepted ' should be returned.
202	The server has accepted the request but has not yet processed it. As it may be rejected, the request may or may not be executed at the end. In the case of asynchronous operation, there is no more convenient way to send this status code. The purpose of a response that returns a 202 status code is to allow the server to accept requests from other processes, such as a batch-based operation that executes only once a day, without having the client remain connected to the server until the batch operation is complete. Responses that accept requests for processing and return a 202 status code should include in the returned entity some information indicating the processing of the current state, as well as pointers to processing status monitors or state predictions so that the user can estimate whether the operation has completed.
203	The server has successfully processed the request, but the returned entity header meta-information is not a valid set on the original server, but a copy from a local or a third party. The current information may be a subset or a superset of the original version. For example, metadata that contains resources may cause the original server to know the meta information is super. It is not necessary to use this status code, and it is appropriate only if the response does not use this status code to return a number of OK.
204	The server successfully processed the request, but did not need to return any entity content, and wanted to return the updated meta information. The response may return new or updated meta information in the form of an entity header. If the header information exists, it should be echoed with the requested variable. If the client is a browser, then the user's browser should keep the page that sent the request without any changes in the document view, even if the new or updated meta information by specification should be applied to the document in the user's browser's active view. Because the 204 response is forbidden to contain any message bodies, it always ends with the first empty line after the message header.
205	The server successfully processed the request and did not return any content. However, unlike the 204 response, a response that returns this status code requires the requestor to reset the document view. The response is primarily used to accept user input and immediately resets the form so that the user can easily start another input. As with the 204 response, the response is also suppressed to contain any message bodies 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 are used to implement a breakpoint continuation or to decompose a large document into multiple download segments for download at the same time. 　　The request must contain the range header information to indicate the scope of content that the client expects, and may contain if-range to be used as a request condition. The Response must contain the following header fields: Content-range to indicate the range of content returned in this response, and if Content-type is a multi-segment download for multipart/byteranges, each The multipart section should contain a Content-range field that indicates the scope of the content of this paragraph. 　　If the response contains Content-length, then its value must match the true number of bytes of the content range it returns. 　　 Date ETag and/or content-location, if the same request should return a 200 response. 　　Expires, Cache-control, and/or Vary, if the value may be different than the value of the other response of the same variable as before. If this response request uses If-range strong cache authentication, then this response should not contain additional entity headers, and if the request for this response uses If-range weak cache authentication, this response prohibits the inclusion of other entity headers This avoids inconsistencies between the cached entity content and the 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 header does not match exactly, the client cache should prevent the content returned by the 206 response from being combined with any previously cached content. Any cache that does not support the Range and Content-range headers suppresses the content returned by caching 206 responses.
207	The status code that is extended by WebDAV (RFC 2518), which represents the following message body, will be an XML message and may contain a series of independent response codes, depending on the number of previous child requests.
300	The requested resource has a range of available feedback information, each with its own specific address and browser-driven negotiation information. The user or browser is able to choose a preferred address to redirect itself. Unless this is a HEAD request, the response should include an entity with a list of resource attributes and addresses so that 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 ability of the browser itself. Of course, the RFC 2616 specification does not specify how such an automatic selection should proceed. If the server itself already has the preferred feedback option, the URI of the feedback should be indicated in the location, which the browser may use as the address for automatic redirection. In addition, this response is cacheable unless otherwise specified.

HTTP status Code detailed