HTTP status Code

1XX Message Status Code

This type of status code, on behalf of which the request has been accepted, needs to be processed. This type of response is a temporary response that contains only the status line and some optional response header information and ends with a blank line. Because no 1XX status codes are defined in the HTTP/1.0 protocol, the server prohibits sending a 1xx response to such clients unless under some experimental conditions.

2XX Success Status Code This type of status code, representing the request has been successfully received, understood, and accepted by the server.OKThe request was successful, and the desired response header or data body will be returned with this response. This status code appears to indicate a normal state.201 CreatedThe 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. 3xx REDIRECT Status code

This type of status code represents the need for the client to take further action to complete the request. Typically, these status codes are used to redirect subsequent request addresses, and subsequent request addresses are indicated in the location domain of the response.

The user's browser can automatically submit required subsequent requests without user intervention, when and only if the method used by subsequent requests is GET or HEAD. The client should automatically monitor for Infinite loop redirection (for example: A->a, or A->b->c->a), as this can result in a large amount of unnecessary resource consumption by the server and the client. The browser should not automatically access more than 5 redirects, as recommended by the Http/1.0 Edition specification.

multiple Choices (multiple options)

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.

301 Moved Permanently (permanent movement)

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, clients that have link editing capabilities should automatically modify the requested address to the address returned from the server. Unless otherwise specified, the response is cacheable.

The new permanent URI should be returned in the location domain of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a short description.

If this is not a GET or HEAD request, the browser disables automatic redirection unless the user confirms it, because the requested condition may vary.

Note: For some browsers that use the http/1.0 protocol, when they send a POST request that gets a 301 response, the next redirect request becomes a Get method.

302 Move temporarily (temporary move)The requested resource temporarily responds to the request from a different URI. Because such redirects are temporary, the client should continue to send subsequent requests to the original address.    This response is cacheable only if specified in Cache-control or expires.    If this is not a GET or HEAD request, then the browser disables automatic redirection unless the user confirms it, because the requested condition may vary. Note: Although the RFC 1945 and RFC 2068 specifications do not allow the client to change the method of the request during redirection, many existing browsers treat the 302 response as a 303 response, and use GET to access the URI specified in the location, ignoring the method originally requested. Status Codes 303 and 307 are added to clarify how the server expects the client to react.303 See other

The response to the current request can be found on another URI, and the client should access that resource in a GET way. This method exists primarily to allow the output of the POST request that is activated by the script to redirect to a new resource. This new URI is not an alternative reference to the original resource. Meanwhile, a 303 response is forbidden to be cached. Of course, a second request (redirect) may be cached.

Note: Many http/1.1 versions of previous browsers do not correctly understand the 303 status. If you need to consider the interaction with these browsers, the 302 status code should be competent, because most browsers handle 302 response in the way that the above specification requires the client to handle the 303 response should be done.

304 not Modified (unmodified)

If the client sends a conditional GET request and the request is allowed, and the contents of the document (since the last time it was accessed or according to the requested condition) have not changed, the server should return the 304 status code. The simple expression is: The client has performed a get, but the file has not changed. The 304 response suppresses the inclusion of 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 a server without a clock follows 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 correctly.

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 strong cache authentication, 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, which avoids inconsistencies between the cached entity content and the updated entity header information.

If a 304 response indicates that the current entity does not have a cache, the caching system must ignore the response and repeat the request with no restrictions.

If you receive a 304 response that requires a cache entry to be updated, the cache system must update the entire entry to reflect all the values of the fields that were updated in the response.

4XX Request Error Status code this type of status code indicates that the client may appear to have an error that prevents the server from processing. Unless the response is a HEAD request, the server should return an entity that interprets the current error condition, and whether this is a temporary or permanent condition. These status codes apply to any request method.    The browser should display to the user any entity content contained in such an error response. If the client is transmitting data when an error occurs, the server implementation using TCP should carefully ensure that the client has received a packet containing the error message before shutting down 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 sends a reset packet to the client to clear all unrecognized input buffers for that client so that the data is not read by the application on the server and interferes with the latter.Request (Error)1, the semantic error, the current request can not be understood by the server.  Unless modified, the client should not submit the request repeatedly. 2, the request parameter is wrong.401 Unauthorized (Unauthorized)

The current request requires user authentication. The response must contain a Www-authenticate information header for the requested resource to ask for user information. The client can repeatedly submit a request that contains the appropriate Authorization header information. If the current request already contains the Authorization certificate, the 401 response indicates that the certificate has been rejected by the server authentication. If the 401 response contains the same authentication query as the previous response, and the browser has tried at least one validation, the browser should show the user the entity information contained in the response, because the entity information may contain related diagnostic information. See RFC 2617.

403 Forbidden (Forbidden)The server has understood the request, but refuses to execute it. Unlike the 401 response, authentication does not provide any help, and the request should not 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 within the entity. Of course the server can also return a 404 response if it does not want the client to get any information.404 Not Found (found)

The request failed and 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 tell the old resources because of some internal configuration mechanism problems, has been permanently unavailable, and there is no jump to the address. 404 This status code is widely used when the server does not want to reveal exactly why the request was rejected or if no other appropriate response is available. The most likely cause of this error is that the server side does not have this page.

405 Method Not allowed (methods not allowed)

The request method specified in the request line cannot be used to request the appropriate resource. The response must return an allow header to indicate a list of request methods that the current resource can accept.

Because the Put,delete method writes to resources on the server, most Web servers do not support or do not allow the above request method under the default configuration, and 405 errors are returned for such requests.

408 Request Timeout (requests timed out)

The request timed out. The client does not complete a request in the time the server is waiting to be sent. The client can submit the request again at any time without making any changes.

413 Request Entity Too Large (requesting entities too large)

The server refuses to process the current request because the size of the entity data submitted by the request exceeds the scope 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 this condition is temporary, the server should return a retry-after response header to tell the client how much time it can retry.

414 Request-uri Too Long (the requested URL is too lengthy)

The requested URI length exceeds the length that the server can interpret, so the server refuses to service the request. This is rare, and the usual situations include:

A form submission that should use the Post method becomes a Get method that causes the query string to be too long.

REDIRECT uri "Black Hole", for example, each redirect takes the old Uri as part of the new URI, resulting in a long URI after several redirects.

The client is trying to exploit a security vulnerability in some servers to attack the server. This type of server uses a fixed-length buffer to read or manipulate the requested URI, and when the GET parameter exceeds a certain value, a buffer overflow may result, causing the malicious code to be executed. A server that does not have such a vulnerability should return a 414 status code.

5XX Service-side error status code

This type of status code indicates that the server has an error or an abnormal state in the process of processing the request, or that the server is aware that the processing of the request cannot be completed with the current hardware and software resources. Unless this is a head request, the server should contain an explanatory information entity that interprets the current error state and whether the condition is temporary or permanent. The browser should show the user any entities that are contained in the current response.

These status codes apply to any response method.

Internal Server error (internal server errors)

The server encountered an unexpected condition that prevented it from completing the processing of the request. In general, this problem occurs when the source code on the server side is wrong.

501 Not implemented (no implementation)

The server does not support a feature that is required for the current request. When the server does not recognize the requested method and cannot support its request for any resource.

502 Bad Gateway (invalid gateways)

An invalid response was received from the upstream server when the server acting as a gateway or agent attempted to execute the request.

For more information, please refer to:

Https://baike.baidu.com/item/HTTP%E7%8A%B6%E6%80%81%E7%A0%81/5053660?fr=aladdin

HTTP status Code