1 xx news
This type of status code indicates that the request has been accepted and needs to continue processing. This type of response is a temporary response, containing only the status line and some optional response header information, and ending with an empty line. Since no 1XX status code is defined in the HTTP/1.0 protocol, the server forbids sending 1XX responses to such clients except under certain test conditions. These status codes represent responses that are informational and indicate other actions the customer should take.
100Continue
The client should continue to send requests. This temporary response is used to inform the client that some of its requests have been received by the server and have not yet been rejected. The client should continue to send the rest of the request, or ignore the response if the request is completed. The server must send a final response to the client after the request completes.
101Switching Protocols
The server has understood the client’s request and will inform the client via the Upgrade header that a different protocol is used to complete the request. After sending the blank line at the end of this response, the server will switch to the protocols defined in the Upgrade header. : This should be done only when switching to a new protocol is more beneficial. For example, switching to a new VERSION of HTTP has advantages over an older version, or switching to a real-time and synchronous protocol to deliver resources that take advantage of such features.
102Processing
Status code extended by WebDAV (RFC2518) to indicate that processing will continue.
2 xx success
This type of status code indicates that the request has been successfully received, understood, and accepted by the server.
200OK
The request was successful, and the desired response header or data body is returned with this response.
201Created
The request has been implemented, and a new resource has been created based on the requirements of the request, and its URI has been returned with the Location header. If the required resource cannot be created in time, return ‘202 Accepted’.
202Accepted
The server has accepted the request but has not yet processed it. Just as it may be denied, ultimately the request may or may not be executed. In the case of asynchronous operations, there is nothing more convenient than sending this status code. The purpose of the response that returns the 202 status code is to allow the server to accept requests for other processes (such as a batch-based operation that is performed only once a day) without having to keep the client connected to the server until the batch operation is complete. A response that accepts request processing and returns a 202 status code should include in the returned entity some information indicating the current status of the processing, as well as Pointers to a process status monitor or state prediction so that the user can estimate whether the operation has completed.
203Non-Authoritative Information
The server has successfully processed the request, but the entity header meta-information returned is not a defined set valid on the original server, but a local or third-party copy. The current information may be a subset or superset of the original version. For example, metadata containing resources can cause the original server to know a superset of meta-information. Using this status code is not required and is only appropriate if the response would have returned 200OK without using this status code.
204No Content
The server successfully processed the request, but does not need to return any physical content and wants to return updated meta-information. The response may return new or updated meta information in the form of entity headers. If such header information exists, it should correspond to the requested variable.
If the client is a browser, the user browser should retain the page from which the request was sent without any changes to the document view, even though according to the specification new or updated meta-information should be applied to the document in the user’s browser active view.
Because the 204 response is prohibited from containing any message body, it always ends with the first blank line after the header.
205Reset Content
The server successfully processed the request and did not return anything. But unlike the 204 response, the response that returns this status code requires the requester to reset the document view. This response is primarily used to reset the form immediately after receiving user input so that the user can easily start another input.
Like the 204 response, this response is disallowed from containing any message body and ends with the first blank line after the header.
206Partial Content
The server has successfully processed some of the GET requests. HTTP download tools such as FlashGet or Xunlei use this type of response to implement breakpoint continuation or break up a large document into multiple download segments at the same time.
The request must contain a Range header indicating the Range of content the client expects, and may contain if-range as a request condition.
The response must contain the following header fields:
Content-range indicates the Range of Content returned in the response; For multipart downloads with a Content-Type of Multipart/Byteranges, each multipart should contain a Content-range field indicating the Content Range of the segment. If the response contains Content-Length, its value must match the true number of bytes in the Content range it returns.
Date
ETag and/or Content-location, if the same request should have returned 200.
Expires, Cache-control, and/or Vary, if their values may differ from those corresponding to other previous responses of the same variable.
If the response request uses if-range strong cache validation, then the response should not contain other entity headers. If the request for this response uses if-range weak cache validation, then the response is prohibited from including other entity headers. This avoids inconsistencies between cached entity content and updated entity header information. Otherwise, the response should contain all of the entity header fields that should have been returned in the 200 response.
If the ETag or Last-Modified headers do not exactly match, the client cache should prohibit combining the 206 response returned with any previously cached content.
Any cache that does not support Range and Content-range headers disallows caching of the 206 response.
207Multi-Status
The status code, extended by WebDAV(RFC2518), indicates that the subsequent message body will be an XML message and may contain a series of independent response codes depending on the number of previous sub-requests.
3 xx redirection
This type of status code indicates that the client needs to take further action to complete the request. Typically, these status codes are used for redirection, and subsequent request addresses (redirect targets) are specified in the Location field of this response.
The user browser can automatically submit the required subsequent requests without user intervention if and only if the subsequent requests are made using a GET or HEAD method. Clients should automatically monitor infinite loop redirects (e.g., A→B→C→… →A or A→A), because this will cause A large amount of unnecessary resource consumption on the server and client. As recommended by the HTTP/1.0 specification, browsers should not automatically access redirects more than five times.
300Multiple Choices
The requested resource has a selection of feedback messages, each with its own specific address and browser-driven negotiation message. The user or browser can choose a preferred address for redirection.
Unless this is a HEAD request, the response should include the entity of a list of resource attributes and addresses from which the user or browser can select 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 capabilities. Of course, the RFC2616 specification does not specify how such automatic selection should be performed.
If the server already has a preferred feedback option, specify the FEEDBACK URI in the Location; The browser may use this Location value as the address for automatic redirection. In addition, the response is also cacheable unless otherwise specified.
301Moved Permanently
The requested resource has been permanently moved to the new location, and any future references to this resource should use one of the several URIs returned by this response. If possible, clients with link editing capabilities should automatically change the requested address to the one that is returned from the server. Unless otherwise specified, the response is also cacheable.
The new persistent URI should be returned in the Location field of the response. Unless this is a HEAD request, the entity responding should contain a hyperlink to the new URI with a short description.
If this is not a GET or HEAD request, the browser forbids automatic redirection unless the user confirms it, because the conditions of the request may change.
Note: For some browsers using HTTP/1.0, if they send a POST request and GET a 301 response, subsequent redirects will become GET requests.
302Found
The requested resource now temporarily responds to the request from a different URI. Since such redirects are temporary, the client should continue to send future requests to the original address. The 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 entity responding should contain a hyperlink to the new URI with a short description.
If this is not a GET or HEAD request, the browser forbids automatic redirection unless the user confirms it, because the conditions of the request may change.
Note: Although the RFC1945 and RFC2068 specifications do not allow clients to change the request method during redirection, many existing browsers treat a 302 response as a 303 response and use GET to access the URI specified in Location, ignoring the original request method. Status codes 303 and 307 have been added to specify what the server expects from the client.
303See Other
The response to the current request can be found at another URI, and the client should access that resource using GET. This method exists primarily to allow the output of POST requests activated by the script to be redirected to a new resource. This new URI is not a substitute reference to the original resource. At the same time, 303 responses are prohibited from being cached. Of course, the second request (redirection) may be cached.
The new URI should be returned in the Location field of the response. Unless this is a HEAD request, the entity responding should contain a hyperlink to the new URI with a short description.
Note: Many browsers prior to HTTP/1.1 do not understand 303 status correctly. If you need to consider interactions with these browsers, the 302 status code should do the job, because most browsers handle 302 responses exactly as the specification requires clients to handle 303 responses.
304Not Modified
If the client sends a conditional GET request and the request is granted, the content of the document has not changed (since the last access or according to the conditions of the request), the server should return this status code. The 304 response disallows the inclusion of a message body and therefore always ends with the first blank line after the message header.
The response must contain the following header information:
Date, unless the server has no clock. If the clock-less server follows these rules, the proxy server and client can add the Date field to the received response header (as specified in RFC2068), and the caching mechanism will work fine.
ETag and/or Content-location, if the same request should have returned 200.
Expires, Cache-control, and/or Vary, if their values may differ from those corresponding to other previous responses of the same variable.
If this response request uses strong cache validation, then this response should not contain other entity headers; Otherwise (for example, if a conditional GET request uses weak cache validation), the response is prohibited from including other entity headers. This avoids inconsistencies between cached entity content and updated entity header information.
If a 304 response indicates that an entity is not currently cached, the caching system must ignore the response and repeat the request without the constraint.
If a 304 response is received asking to update a cache entry, the cache system must update the entire entry to reflect the values of all fields updated in the response.
305Use Proxy
The requested resource must be accessed through the specified proxy. The Location field gives the URI information for the specified proxy, and the receiver needs to send a separate request repeatedly to access the resource through this proxy. Only the original server can create the 305 response.
Note: RFC2068 does not specify that the 305 response is to redirect a single request and can only be created by the original server. Ignoring these restrictions can have serious security consequences.
306Switch Proxy
In the latest version of the specification, the 306 status code is no longer used.
307Temporary Redirect
The requested resource now temporarily responds to the request from a different URI. Since such redirects are temporary, the client should continue to send future requests to the original address. The 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 entity responding should contain a hyperlink to the new URI with a short description. Because some browsers do not recognize the 307 response, you need to add the necessary information so that users can understand and request access to the new URI.
If this is not a GET or HEAD request, the browser forbids automatic redirection unless the user confirms it, because the conditions of the request may change.
4XX Client error
Such status codes indicate that the client appears to have made an error that interferes with the server’s processing. Unless responding to a HEAD request, the server should return an entity that explains the current error condition and whether it is temporary or permanent. These status codes apply to any request method. The browser should show the user any entity content contained in such an error response.
If the client is transmitting data when the error occurs, the server implementation using TCP should be careful to ensure that the client has received the packet containing the error message before closing the connection between the client and the server. If the client continues to send data to the server after receiving an error message, the server’s TCP stack sends a reset packet to the client to clear the client of any unrecognized input buffers before they are read and interfered with by the application on the server.
400Bad Request
The current request is not understood by the server due to a syntax error. The client should not re-submit this request unless it is modified.
401Unauthorized
The current request requires user authentication. The response must include a WWW-Authenticate header applicable to the requested resource to ask for user information. The client can repeatedly submit a request with the appropriate Authorization header information. If the current request already contains Authorization certificates, the 401 response represents server validation that 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 show the user the entity information contained in the response, as this entity information may contain relevant diagnostic information. See RFC2617.
402Payment Required
This status code is reserved for possible future requirements.
403Forbidden
The server understands the request, but refuses to execute it. Unlike the 401 response, authentication does not help, and the request should not be submitted twice. If this is not a HEAD request and the server wants to be able to explain why the request cannot be executed, the reason for the rejection should be described in the entity. Of course, the server can also return a 404 response if it doesn’t want the client to get any information.
404Not Found
The requested resource was not found on the server. There is no information to tell the user whether the condition is temporary or permanent. If the server is aware of the situation, it should use the 410 status code to tell the old resource that it is permanently unavailable due to some internal configuration mechanism and that there are no reachable addresses. The 404 status code is widely used when the server does not want to reveal exactly why the request was rejected or when no other suitable response is available.
405Method Not Allowed
The request method specified in the request line cannot be used to request the corresponding resource. The response must return an Allow header representing a list of request methods that the current resource can accept.
Because the PUT and DELETE methods write to the resources on the server, most web servers do not support or do not allow these methods by default, and return 405 errors for such requests.
406Not Acceptable
The content characteristics of the requested resource do not satisfy the condition in the request header, and therefore the response entity cannot be generated.
Unless this is a HEAD request, the response should return an entity with an address list that allows the user or browser to select the most appropriate entity feature from the list. The format of the entity is determined by the media Type defined in the Content-Type header. The browser can make the best choice based on the format and its capabilities. However, the specification does not define any criteria for making such automatic choices.
407Proxy Authentication Required
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 questioning. The client can return a proxy-authorization header for authentication. See RFC2617.
408Request Timeout
The request timed out. The client did not finish sending a request within the time the server was waiting. The client can submit this request again at any time without making any changes.
409Conflict
The request could not be completed because of a conflict with the current state of the requested resource. This code is allowed to be used only when the user is deemed capable of resolving the conflict and will resubmit a new request. The response should contain enough information for the user to discover the source of the conflict.
Conflicts usually occur in the processing of PUT requests. For example, in an environment where version checking is used, if the version information accompanying a PUT request to modify a particular resource conflicts with a previous (third-party) request, the server should return a 409 error informing the user that the request could not be completed. At this point, the response entity is likely to contain a comparison of the differences between the two conflicting versions so that the user can resubmit the new version after merging.
410Gone
The requested resource is no longer available on the server and does not have any known forwarding address. Such conditions should be considered permanent. If possible, clients with link editing capabilities should remove all references to this address with the user’s permission. If the server does not know or cannot determine whether the condition is permanent, the 404 status code should be used. Unless otherwise noted, the response is cacheable.
The main purpose of the 410 response is to help the webmaster maintain the site by notifying the user that the resource is no longer available and that the server owner wants all remote connections to the resource to be removed. Such events are common in time-limited, value-added services. Similarly, the 410 response is used to inform clients that resources that once belonged to an individual are no longer available on the current server site. Of course, it is entirely up to the server owner to mark all permanently unavailable resources as ‘410 Gone’ and to keep that mark for how long.
411Length Required
The server refuses to accept a request without defining the Content-Length header. After adding a valid Content-Length header indicating the Length of the request message body, the client can submit the request again.
412Precondition Failed
The server failed to meet one or more of the prerequisites when verifying that they were given in the header field of the request. This status code allows a client to set a prerequisite in the request meta-information (request header field data) when acquiring a resource, preventing the request method from being applied to a resource other than its desired content.
413Request Entity Too Large
The server refused to process the current request because the size of entity data submitted by the request was larger than the server was willing or able to process. In this case, the server can close the connection to prevent the client from continuing to send the request.
If the condition is temporary, the server should return a retry-after response header to tell the client how long it can Retry.
414Request-URI Too Long
The request URI was longer than the server could interpret, so the server refused to service the request. This is rare. Common cases include:
A form submission that should have used the POST method became a GET method, resulting in an excessively long Query String.
Redirection URI “black holes”, such as the old URI being part of the new one with each redirection, result in the URI being too long after several redirects.
The client is trying to exploit a security vulnerability in some servers. Such servers use a fixed-length buffer to read or manipulate the URI of the request, and when the parameters after GET exceed a certain value, a buffer overflow may occur, causing arbitrary code to be executed [1]. Servers without such vulnerabilities should return a 414 status code.
415Unsupported Media Type
For the currently requested method and requested resource, the submitted entity in the request is not in a format supported by the server, so the request is rejected.
416Requested Range Not Satisfiable
If the request contains a Range header, any data Range specified in the Range does not overlap with the available Range of the current resource, and If an IF-range header is not defined in the request, the server should return a 416 status code.
If Range uses a byte Range, then the first byte positions of all data ranges specified by the request exceed the length of the current resource. The server should also return a 416 status code with a Content-Range entity header that indicates the length of the current resource. The response is also disallowed from using multipart/ Byteranges as its content-Type.
417Expectation Failed
The expected content specified in request header Expect cannot be satisfied by the server, or the server is a proxy server that has clear evidence that Expect’s content cannot be satisfied at the next node of the current route.
418I’m a teapot
This opcode was defined in 1998 as the IETF’s traditional April fool’s joke in the RFC2324 hypertext coffee-pot control protocol and does not need to be defined in a real HTTP server.
421There are too many connections from your internet address
The number of connections to the server from the current client’s IP address exceeded the maximum allowed by the server. In general, 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 calculation may involve more than one end user.
422Unprocessable Entity
The request was well-formed, but could not be responded to due to semantic errors. (RFC4918WebDAV)
423Locked
The current resource is locked. (RFC4918WebDAV)
424Failed Dependency
The current request failed due to an error in a previous request, such as PROPPATCH. (RFC4918WebDAV)
425Unordered Collection
Defined in the WebDav Advanced Collections draft, but not in the WebDav sequential set protocol (RFC3658).
426Upgrade Required
The client should switch to TLS/1.0. (RFC2817)
449Retry With
Extended by Microsoft to mean that the request should be retried after the appropriate action has been performed.
5XX Server error
This status code indicates that an error or exception occurs when the server processes the request. It may also indicate that the server realizes that the current hardware and software resources cannot complete the request processing. Unless this is a HEAD request, the server should contain an explanation entity that explains the current error state and whether the state is temporary or permanent. The browser should show the user any entities that are included in the current response.
These status codes are applicable to any response method.
500Internal Server Error
The server encountered an unexpected condition that prevented it from completing processing the request. Typically, this problem occurs when the server’s code fails.
501Not Implemented
The server does not support a feature required for the current request. When the server does not recognize the requested method and cannot support its request for any resource.
502Bad Gateway
An invalid response was received from the upstream server when a server working as a gateway or proxy tried to execute the request.
503Service Unavailable
The server is currently unable to process requests due to temporary server maintenance or overload. The situation is temporary and will recover over time. If the delay time is expected, the response can include a retry-after header to indicate the delay time. If this retry-after information is not given, the client should process it as if it were a 500 response.
504Gateway Timeout
When a server working as a gateway or proxy tries to execute a request, it fails to receive a response from an upstream server (a server identified by a URI, such as HTTP, FTP, or LDAP) or a secondary server (such as DNS) in a timely manner.
Note: Some proxy servers will return 400 or 500 errors when DNS queries time out
505HTTP Version Not Supported
The server does not support, or refuses to support, the HTTP version used in the request. This implies that the server cannot or will not use the same version as the client. The response should include an entity that describes why the version is not supported and which protocols are supported by the server.
506Variant Also Negotiates
Extended by the Transparent Content Negotiation Protocol (RFC2295), this means that the server has an internal configuration error: the requested negotiated argument resource is configured to use itself in transparent content negotiation and is therefore not an appropriate focus in a negotiation processing.
507Insufficient Storage
The server could not store the content necessary to complete the request. The situation is considered temporary. WebDAV (RFC4918)
509Bandwidth Limit Exceeded
The server reached the bandwidth limit. Procedure This is not an official status code, but it is still widely used.
510Not Extended
The strategy required to acquire the resource is not met