HTTP status code summary

##Extended by WebDAV (RFC 2518) The status code indicates that processing will continue.

##200

The request was successful and the request was requested The response header or data body will be returned with this response.

##201

##202

The server successfully processed the request and returned nothing. 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

The server has successfully processed a partial GET ask. HTTP download tools like FlashGet or Thunder use this type of response to resume interrupted downloads or 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 wishes to obtain, 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 Content-Type is multipart/byteranges For multi-part downloads, each multipart part should contain a Content-Range field to indicate the content range of this part. 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 to 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 validation, 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 the Range and Content-Range headers is prohibited from caching the content returned by the 206 response.

##The requested resource has a list of available resources Alternative feedback messages, 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 selection, 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.

##The requested resource has been permanently moved to the 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

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. 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

The response corresponding to the current request can be in is found on 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.

##The requested resource must be specified by agent can be accessed. The Location field will give the URI information where the specified proxy is located. The recipient needs to repeatedly send a separate request to access the corresponding resource through this proxy. Only the origin server can establish a 305 response. Note: RFC 2068 does not specify that a 305 response is intended to redirect a single request and can only be established by the origin server. Ignoring these restrictions can lead to serious safety consequences.

##In the latest version of the specification, The 306 status code is no longer used.

307

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 submit it to new users. URI makes access request. 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.

400

1. The semantics are incorrect. Currently The request cannot be understood by the server. The client should not resubmit this request unless modified. 2. The request parameters are incorrect.

401

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. If the current request already included 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

##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

The content attribute of the requested resource cannot be The condition in the request header is met, 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

Similar to the 401 response, except that the client must authenticate on the proxy server. The proxy server must return a Proxy-Authenticate for identity queries. The client can return a Proxy-Authorization header for verification. See RFC 2617.

408

##The request timed out. 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.

##The server rejects content- Accept the request without the Length header. After adding a valid Content-Length header indicating the length of the request message body, the client can submit the request again.

##The server is verifying the header in the request When prerequisites are given in the fields, one or more of them are not met. 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

414

The requested URI is longer than the server can interpret, so the server refuses to service 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. The client is trying to exploit the security holes in some servers to attack the server. This type of server uses a fixed-length buffer to read or operate requests. URI, when the parameters after GET exceed a certain value, buffer overflow may occur, causing arbitrary code to be executed [1]. Servers without such vulnerabilities should return a 414 status code.

##415

##From the IP of the current client The number of connections from the address to the server exceeds the maximum allowed range of 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

##422

424

425

The server encountered an unexpected condition that prevented it from completing processing of the request. Generally speaking, this problem will occur when there is an error in the server's program code.

##501

The server does not support what the current request requires a certain function. When the server does not recognize the requested method and cannot support its request for any resource.

##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 a delay can be expected, the response can include a Retry-After header to indicate the delay. If this Retry-After message is not given, the client SHOULD handle it the same way it handles a 500 response. Note: The existence of the 503 status code does not mean that the server must use it when it is overloaded. Some servers simply wish to deny connections from clients.

##A server that works as a gateway or proxy When trying to execute a request, a response was not received in time from the upstream server (the server identified by the URI, such as HTTP, FTP, LDAP) or the secondary server (such as DNS). Note: Some proxy servers will return a 400 or 500 error

##505

##510

##Get the strategies required for the resource and Not satisfied. (RFC 2774)