HTTP status Code classification and exception status code processing

1XX: Indicates a temporary response
100: (continued) The requesting person shall continue to make the request. The server returns this code to indicate that the first part of the request was received and is waiting for the remainder
101: (switching protocol) The requestor has asked the server to switch protocols, the server has confirmed and is ready to switch

2XX: Indicates the status code of the request was successfully processed
200 (successful) the server has successfully processed the request, which typically indicates that the server provided the requested page
204 (reset content) the server successfully processed the request, but did not return any content
206 (partial) The server successfully processed a partial GET request

3xx (redirect): Indicates that further action is required to complete the request. Typically, these status codes are used to redirect
301: (permanently moved) The requested page has been permanently moved to the new location. When the server returns this response (response to get and head requests), the requestor is automatically forwarded to the new location
302 (Temporary move) The server is currently responding to a request from a Web page in a different location, but the requestor should continue to use the original location for future requests
303 (View other locations) The server returns this code when the requestor should use a separate GET request for the different locations to retrieve the response
304 (not modified) The requested page has not been modified since the last request. When the server returns this response, the Web page content is not returned

4xx (Request error): These status codes indicate a possible error in the request and prevent the server from processing
400: (Error request) The server does not understand the syntax of the request
401 (unauthorized) request authentication is required. The server may return this response for pages that need to log on
403 (Forbidden) the server denies the request
404 (Not found) the server could not find the requested Web page
405 (method Disabled) Disables the method specified in the request
406 (not accepted) The requested Web page cannot be responded to using the requested content attribute
408 (Request timed out) timeout occurs when the server waits for a request
414 (The requested URI is too long) the URI of the request (usually the URL) is too long and the server cannot process
415 (Unsupported media type) The requested format is not supported by the requested page
416 (Request scope does not meet the requirements) if the page cannot provide the requested range, the server returns this status code

499

5XX (server error) These status codes indicate that the server has an internal error while trying to process the request. These errors may be the error of the server itself, not the request error
500 (server internal error) the server encountered an error and could not complete the request
501 (not implemented) the server does not have the ability to complete the request, for example, this code may be returned when the server does not recognize the request method
502 (Bad Gateway) server receives an invalid response from the upstream server as a gateway and proxy
503 (server unavailable) the server is not currently available (due to overloading or downtime maintenance). Usually, it's just a temporary state.
504 (Gateway Timeout) The server acts as a gateway or proxy, but does not receive requests from the upstream server in a timely manner
505 (HTTP version not supported) server does not support the HTTP protocol version used in the request

428 Precondition Required (prerequisites required)
A prerequisite is when a client sends an HTTP request that must meet some preset criteria if it wants the request to succeed.
A good example is the If-none-match header, which is often used in GET requests, and if If-none-match is specified, then the client receives the response only after the ETAG in the response has changed.
Another example of a prerequisite is the If-match header, which is typically used on PUT requests to indicate that only resources that have not been changed are updated, which is used to prevent the same content from being overwritten by multiple clients using HTTP services.
When the server side uses the 428 precondition Required status code, it means that the client must send the above request header to execute the request, which provides an effective way for the server to prevent the ' lost update ' issue.

429 Too Many requests (too many requests)
This status code is useful when you need to limit the number of clients requesting a service, which is the request speed limit.
Prior to this, there were some similar status codes, such as ' 509 Bandwidth Limit exceeded '. Twitter uses 420 (this is not an HTTP defined status code)
If you want to limit the number of client requests to a service, you can use a 429 status code and include a retry-after response header to tell the client how long it will take to request the service again.

431 Request Header Fields Too Large (header field too large)
In some cases, the client sends the HTTP request header to become very large, then the server can send 431 request header fields Too Large to indicate the problem.
I am not quite sure why there is no 430 status code, but jump straight from 429 to 431, I try to search but no results. The only guess is 430 Forbidden and 403 Forbidden too like, in order to avoid confusion to do so, God knows!

511 Network authentication Required (authentication required)
This status code is interesting to me, and if you're developing an HTTP server, you don't have to deal with that status code, but if you're writing an HTTP client, the status code is very important.
If you use laptops and smartphones frequently, you may notice that a large number of public WIFI services require you to accept some protocols or you must log in before you can use them.
This is annoying by intercepting HTTP traffic and returning a redirect and login when a user tries to access the network, but this is the case.

With these "intercept" clients, there are some nasty side effects. Examples of these two are mentioned in the RFC:

If you visit a website before you log in to WiFi, the network device will intercept the first request, and these devices often have their own website icon ' Favicon.ico '. After logging in, you will find that the website icon you visited for a while has been the icon of the WiFi login website.
If a client uses an HTTP request to find a document (possibly JSON), the network responds to a login page so that your client resolves the error and causes the client to run the exception, which is a common problem in reality.
So the 511 status code is proposed to solve this problem.

If you are writing an HTTP client, you might want to check the 511 status code to verify that authentication is required before you can access it.

HTTP status Code classification and exception status code processing