Popular science literacy, HTTP Status Code details, from now on the wrong!

200 The server successfully returned page 404 not found 503 Service unavailable

1XX (Interim response)

A status code that represents a temporary response and requires the requester to continue executing the operation.

100 (Continue) The requester should continue to make the request. The server returns this code to indicate that it has received the first part of the request and is waiting for the rest.
101 (Switching protocol) The requester has asked the server to switch protocol, and the server has confirmed and is ready to switch.

2XX (Success)

A status code that indicates that the request was successfully processed.

200 (Success) The server has successfully processed the request. Typically, this means that the server has provided the requested web page.
201 (Created) The request succeeded and the server created a new resource.
202 (Accepted) The server has accepted the request but has not yet processed it.
203 (Unauthorized Information) The server has successfully processed the request, but the information returned may come from another source.
204 (No content) The server successfully processed the request, but did not return any content.
205 (Reset Content) The server successfully processed the request, but did not return any content.
206 the server successfully processed some OF the GET requests.

3xx (Redirection)

Indicates that further action is required to complete the request. Typically, these status codes are used for redirects.

300 (Multiple options) The server can perform a variety of operations on a request. The server can select an operation based on the requester (User Agent) or provide a list of operations for the requester to select.
The page for request 301 (Permanent move) has been permanently moved to a new location. When the server returns this response (a response to a GET or HEAD request), it automatically forwards the requester to the new location.
The 302 (temporary mobile) server currently responds to requests from web pages in different locations, but requesters should continue to use the original location for future requests.
303 (View other locations) The server returns this code when the requester should use a separate GET request for a different location to retrieve the response.
304 (Unmodified) The requested page has not been modified since the last request. When the server returns this response, the web page content is not returned.
305 (Using a proxy) The requester can only access the requested web page using a proxy. If the server returns this response, it also indicates that the requester should use a proxy.
307 (temporary redirection) The server currently responds to requests from web pages in different locations, but the requester should continue to use the original location for future requests.

4xx (Request error)

These status codes indicate that the request may be in error, preventing the server from processing it.

400 (Error request) Server does not understand the syntax of the request.
The 401 (unauthorized) request requires authentication. The server may return this response for a web page that requires login.
403 (Forbidden) The server rejects the request.
404 (Not found) The server could not find the requested page.
405 (method disable) Disables the method specified in the request.
406 (Not accepted) Web pages that cannot respond to a request using the requested content feature.
407 (Proxy authorization required) This status code is similar to 401 (unauthorized), but specifies that the requester should authorize the use of the proxy.
408 (Request Timeout) The server timed out while waiting for a request.
409 (Conflict) A server conflict while completing a request. The server must include information about the conflict in the response.
410 (Deleted) The server returns this response if the requested resource has been permanently deleted.
411 (Valid length required) The server will not accept requests that do not contain a valid content length header field.
412 (Conditions not met) The server does not meet one of the conditions set by the requester in the request.
413 (Request entity too large) The server cannot process the request because the request entity is too large for the server to handle.
414 (Request URI too long) The request URI (usually the url) is too long for the server to process.
415 (Unsupported media Type) The requested format is not supported by the requested page.
416 (Requested scope not required) If the page cannot provide the requested scope, the server returns this status code.
417 (Unmet Expectations) The server did not meet the requirements for the “expected” request header field.

5xx (Server error)

These status codes indicate that an internal error occurred while the server was trying to process the request. These errors may be server errors rather than request errors.

500 (Server internal error) The server encountered an error and could not complete the request.
The 501 (not yet implemented) server does not have the capability to complete requests. For example, the server may return this code if it does not recognize the request method.
502 (Error Gateway) server, acting as gateway or proxy, received invalid response from upstream server.
503 (Service unavailable) The server is currently unavailable (due to overloading or downtime for maintenance). Usually, this is a temporary state.
504 (Gateway Timeout) The server acted as a gateway or proxy, but did not receive the request from the upstream server in time.
505 (HTTP version not supported) The server does not support the HTTP protocol version used in the request.

RFC 6585 has just been released, and this document describes four new HTTP status codes.

HTTP protocol still changing? Yes, the HTTP protocol is evolving all the time, and new status codes are very useful for developing REST services, or HTTP-based services. Here we describe these four new status codes and whether they should be used.

The Precondition is that when the client sends the HTTP request, there are preconditions that must be met if the request is to succeed.

A good example is the if-none-match header, often used in GET requests. If if-none-match is specified, the client will only re-receive the response If the ETag in the response changes.

Another example of a prerequisite is the if-match header, which is commonly used on PUT requests to indicate that only unchanged resources are updated. This is used to prevent multiple clients from overwriting the same content when using HTTP services.

When the server side uses the 428 Feed Required state code, which means the client must send the above request header to execute the request, this method provides the server with an efficient way to prevent the ‘Lost Update’ problem.

This status code is useful when you need to limit the number of Requests a client can make for a particular service, known as request speed limits.

Before this, there are 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 requests a client can make to the service, use a 429 status code with a retry-after response header that tells the client how long it will take to request the service again.

431 Request Header Fields Too Large In some cases, the client sends an HTTP Request Header that is Too Large. The server can send 431 Request Header Fields Too Large to indicate the problem.

511 Network Authentication Required This status code is interesting to me. If you are developing an HTTP server, you don’t necessarily need to deal with this status code, but if you are writing an HTTP client, this status code is very important.

If you’re a heavy user of your laptop and smartphone, you’ve probably noticed that a lot of public WIFI services require you to accept some protocol or log in to use them. This is done by intercepting HTTP traffic, which returns a redirect and login when the user tries to access the network, which is annoying, but it’s actually the case. There are some nasty side effects to using these “intercepting” clients. There are examples of both mentioned in the RFC:

If you visit a website before logging on to WIFI, networking devices will block the first request, and these devices tend to have their own website icon ‘favicon.ico’. After logging in, you will find that the icon of the site you visit has been the icon of the WIFI login site for a period of time.

If a client uses an HTTP request to find a document (possibly JSON), the network will respond with a login page, and your client will parse the error and cause the client to run abnormally, which is a very common problem in the real world.

Therefore, the 511 status code is proposed to solve this problem.

If you’re writing an HTTP client, you’d better check the 511 status code to see if authentication is required to access it.

Author: Zhang Shanyou

The original link below: http://www.cnblogs.com/shanyou/archive/2012/05/06/2486134.html

Long press concern public number