| Status code |
Meaning |
| 100 |
The client should continue to send the request. This interim response is used to inform the client that its part of the request has been accepted by the server and has not been rejected. The client should continue to send the rest of the request, or ignore this response if the request has been completed. The server must send a final response to the client after the request is completed. |
| 101 |
The server has understood the client's request and will inform the client through the Upgrade message header to use a different protocol to complete the request. After sending the last blank line of this response, the server will switch to the protocols defined in the Upgrade message header.
Such actions should only be taken when there is a benefit to switching to a new protocol. For example, switching to a new HTTP version that has advantages over an old one, or switching to a real-time and synchronous protocol to transfer resources that take advantage of such features. |
| 102 |
Status code extended by WebDAV (RFC 2518) indicating that processing will continue. |
| 200 |
The request was successful, and the expected response headers or data body will be returned with this response. |
| 201 |
The request has been fulfilled, and a new resource has been created based on the request, and its URI has been returned with the Location header information. If the required resource cannot be created in time, '202 Accepted' should be returned. |
| 202 |
The server has accepted the request but has not yet processed it. Just as it could be rejected, the request may or may not be executed in the end. In the case of asynchronous operations, there is no more convenient way than sending this status code.
The purpose of returning a response with a 202 status code is to allow the server to accept requests for other processes (such as a batch-based operation that is only executed once a day) without having to keep the client connected to the server until the batch operation is completed. The response that accepts the request and returns a 202 status code should include some information indicating the current status of the processing in the returned entity, as well as a pointer to a processing status monitor or status prediction so that the user can estimate whether the operation has been completed. |
| 203 |
The server has successfully processed the request, but the returned entity header meta information is not the definitive set valid on the original server, but comes from a local or third-party copy. The current information may be a subset or superset of the original version. For example, including metadata about a resource may result in the origin server knowing the source of the meta-information. Use of this status code is optional, and is only appropriate if the response would otherwise be a 200 OK. |
| 204 |
The server successfully processed the request, but does not need to return any entity content, and wishes to return updated metainformation. The response MAY return new or updated metainformation in the form of entity headers. If present, these headers SHOULD correspond to the requested variant.
If the client is a browser, the user's browser SHOULD retain the page from which the request was sent, without making any changes to the document view, even though the specification SHOULD apply the new or updated metainformation to the document in the user's browser's active view.
Since a 204 response MUST NOT contain any message body, it always ends with the first empty line after the message headers. |
| 205 |
The server successfully processed the request, and did not return any content. However, unlike the 204 response, the 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 also prohibited from containing any message body and ends with the first blank line after the message header. |
| 206 |
The server has successfully processed part of the GET request. HTTP download tools such as FlashGet or Xunlei use this type of response to implement breakpoint resuming or to break a large document into multiple download segments for simultaneous download.
The request must contain the Range header information to indicate the content range that the client wants to obtain, and may contain If-Range as a request condition.
The response MUST include the following header fields:
Content-Range indicates the range of content to be returned in this response; if the Content-Type is multipart/byteranges, each multipart segment should include a Content-Range field to indicate the content range of this segment. If the response includes Content-Length, 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 would have returned a 200 response.
Expires, Cache-Control, and/or Vary, if their values may be different from those of other responses to the same variant.
If the request for this response uses the If-Range strong cache validation, then this response SHOULD NOT include other entity headers; if the request for this response uses the If-Range weak cache validation, then this response MUST NOT include other entity headers; this avoids inconsistencies between cached entity content and updated entity header information. Otherwise, this response SHOULD include all entity header fields that would have been returned in a 200 response.
If the ETag or Last-Modified headers do not match exactly, client caches should not combine the content returned in a 206 response with any previously cached content.
Any cache that does not support the Range and Content-Range headers should not cache the content returned in a 206 response. |
| 207 |
Status code extended by WebDAV (RFC 2518) indicating that the following message body will be an XML message and may contain a series of independent response codes depending on the number of previous subrequests. |
| 300 |
The requested resource has a series of possible responses, each with its own specific address and browser-driven negotiation information. The user or browser can select a preferred address for redirection.
Unless this is a HEAD request, the response SHOULD include an entity with a list of resource characteristics and addresses from which the user or browser can select the most appropriate redirection 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, RFC 2616 does not specify how such automatic selection should be made.
If the server already has a preferred feedback choice, the feedback URI should be specified in Location; the browser may use this Location value as the address for automatic redirection. In addition, unless otherwise specified, this response is also cacheable. |
| 301 |
The requested resource has been permanently moved to a new location, and any future references to this resource should use one of the 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 must not automatically redirect unless the user confirms that the request conditions may have changed.
Note: For some browsers using the HTTP/1.0 protocol, when a POST request they send receives a 301 response, the subsequent redirect request will become a GET method. |
| 302 |
The requested resource is now temporarily responding to requests from a different URI. Because this redirection is 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.
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 is prohibited from automatically redirecting unless the user confirms it, because the conditions of the request may change.
Note: Although RFC 1945 and RFC 2068 do not allow clients to change the request method when redirecting, many existing browsers treat 302 responses as 303 responses and use GET to access the URI specified in Location, regardless of the original request method. Status codes 303 and 307 were added to clarify what response the server expects from the client. |
| 303 |
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 script-activated POST requests to redirect to a new resource. The new URI is not a replacement reference to the original resource. Also, 303 responses MUST NOT be cached. However, the second request (the redirect) MAY be cached.
The new URI SHOULD be returned in the Location field of the response. Unless this is a HEAD request, the entity of the response SHOULD contain a hyperlink to the new URI and a brief description.
Note: Many browsers prior to HTTP/1.1 do not understand the 303 status correctly. If interaction with these browsers is a concern, the 302 status code should suffice, since most browsers handle 302 responses in exactly the same way that the above specification requires clients to handle 303 responses. |
| 304 |
The server SHOULD return this status code if the client has sent a conditional GET request and the request is allowed, and the document's contents have not changed (since the last access or according to the request's conditions). A 304 response MUST NOT include a message-body, and therefore always ends with the first blank line after the headers.
The response MUST include the following headers:
Date, unless the server does not have a clock. If servers without clocks follow these rules, proxies and clients MAY add the Date field to the received response headers (as specified in RFC 2068), and caching will work properly.
ETag and/or Content-Location, if the same request would have otherwise returned a 200 response.
Expires, Cache-Control, and/or Vary, if their values might differ from those of other responses to the same variant.
If this response request uses strong cache validation, then this response should not contain other entity headers; otherwise (for example, a conditional GET request uses weak cache validation), this response MUST NOT contain 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 cache system must ignore this response and repeat the request without the restriction.
If a 304 response is received requesting an update of a cache entry, the cache system must update the entire entry to reflect the values of all fields updated in the response. |
| 305 |
The requested resource must be accessed through the specified proxy. The Location field will give the URI information of the specified proxy, and the recipient needs to repeat a separate request to access the corresponding resource through this proxy. Only the origin server can create a 305 response.
Note: RFC 2068 does not specify that the 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 security consequences. |
| 306 |
In the latest version of the specification, the 306 status code is no longer used. |
| 307 |
The requested resource is now temporarily responding to requests from a different URI. Since this redirection is 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.
The new temporary URI SHOULD be returned in the Location field of the response. Unless this is a HEAD request, the entity of the response SHOULD contain a hyperlink to the new URI and a brief description. Because some browsers do not recognize the 307 response, it is necessary to add the necessary information so that users can understand and make access requests to the new URI.
If this is not a GET or HEAD request, the browser is prohibited from automatically redirecting unless the user confirms it, because the conditions of the request may change. |
| 400 |
1. The semantics are incorrect and the current request cannot be understood by the server. Unless modified, the client should not resubmit this request.
2. The request parameters are incorrect. |
| 401 |
The current request requires user authentication. The response must contain a WWW-Authenticate header applicable to the requested resource to ask for user information. The client can resubmit a request containing the appropriate Authorization header information. If the current request already contains Authorization credentials, the 401 response means that the server has rejected those credentials. If a 401 response contains the same authentication challenge as a previous response, and the browser has already attempted authentication at least once, then the browser SHOULD display the entity contained in the response to the user, as this entity may contain relevant diagnostic information. See RFC 2617. |
| 402 |
This status code is reserved for possible future use. |
| 403 |
The server understood the request, but is refusing to perform it. Unlike the 401 response, authentication does not provide any assistance, and the request SHOULD NOT be repeated. If this is not a HEAD request, and the server wishes to explain why the request cannot be performed, then the reason for the refusal SHOULD be stated in the entity. The server MAY also return a 404 response if it does not wish to make any information available to the client. |
| 404 |
The request failed. The resource requested was not found on the server. There is no information to tell the user whether this situation is temporary or permanent. If the server knows the situation, it should use the 410 status code to inform that the old resource is permanently unavailable due to some internal configuration mechanism problems, and there is no address to jump to. The 404 status code is widely used when the server does not want to reveal why the request was rejected or no other suitable response is available. |
| 405 |
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 to the resources on the server, most web servers do not support or do not allow the above request methods under the default configuration, and will return 405 errors for such requests. |
| 406 |
The content characteristics of the requested resource do not meet the conditions in the request header, so no response entity can be generated.
Unless this is a HEAD request, the response should return an entity containing entity characteristics and a list of addresses from which the user or browser can choose the most appropriate one. 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 own capabilities. However, the specification does not define any standard for making such automatic choices. |
| 407 |
Similar to the 401 response, except that the client must authenticate itself with the proxy server. The proxy server must return a Proxy-Authenticate for identity query. The client can return a Proxy-Authorization header for verification. See RFC 2617. |
| 408 |
Request timeout. The client did not complete a request within the time the server was prepared to wait. The client can resubmit this request at any time without making any changes. |
| 409 |
The request could not be completed due to a conflict with the current state of the requested resource. This code is only allowed in such a case: the user is considered to be able to resolve the conflict and 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, the version information attached to a PUT request to modify a specific resource conflicts with a previous (third-party) request. In this case, the server should return a 409 error to inform the user that the request could not be completed. At this time, the response entity is likely to contain a difference comparison between the two conflicting versions so that the user can resubmit the merged new version. |
| 410 |
The requested resource is no longer available on the server and there is no known forwarding address. This condition should be considered permanent. If possible, clients with link editing capabilities should remove all references to this address after obtaining user permission. If the server does not know or cannot determine whether this condition is permanent, then the 404 status code should be used. Unless otherwise specified, this response is cacheable.
The purpose of the 410 response is mainly to help website administrators maintain the website, notifying users that the resource is no longer available and that the server owner hopes that all remote links to this resource will also be deleted. This type of event is common in limited-time, value-added services. Similarly, the 410 response is also used to notify clients that resources originally belonging to a certain individual are no longer available on the current server site. Of course, whether all permanently unavailable resources need to be marked as '410 Gone' and how long this mark should be maintained is entirely up to the server owner. |
| 411 |
The server refuses to accept the request without a defined Content-Length header.Request. The client can submit the request again after adding a valid Content-Length header indicating the length of the request message body. |
| 412 |
The server failed to meet one or more of the preconditions given in the request header field when verifying the request. This status code allows the client to set preconditions in the request meta-information (request header field data) when obtaining resources, thereby preventing the request method from being applied to resources other than the expected content. |
| 413 |
The server refuses to process the current request because the size of the entity data submitted by the request exceeds the range that the server is willing or able to process. 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 try again. |
| 414 |
The length of the requested URI exceeds the length that the server can interpret, so the server refuses to provide service for the request. This is relatively rare, and common situations include:
The form submission that should have used the POST method became the GET method, resulting in a query string that is too long.
Redirect URI "black hole", for example, each redirection uses the old URI as part of the new URI, resulting in the URI being too long after several redirections.
The client is trying to exploit security vulnerabilities in some servers to attack the server. Such servers use a fixed-length buffer to read or operate the requested URI. When the parameter after GET exceeds a certain value, a buffer overflow may occur, resulting in arbitrary code execution[1]. Servers without such vulnerabilities should return a 414 status code. |
| 415 |
The entity submitted in the request is not in a format supported by the server for the requested method and resource, so the request is rejected. |
| 416 |
If the request contains a Range request header, and any data range specified in the Range does not overlap with the available range of the current resource, and the request does not define an If-Range request header, then the server should return a 416 status code.
If the Range uses a byte range, then this means that the first byte position of all data ranges specified in the request exceeds the length of the current resource. The server should also include a Content-Range entity header to indicate the length of the current resource when returning the 416 status code. This response is also prohibited from using multipart/byteranges as its Content-Type. |
| 417 |
The expected content specified in the request header Expect cannot be met by the server, or the server is a proxy server, and there is clear evidence that the content of Expect cannot be met at the next node in the current route. |
| 421 |
The number of connections from the current client's IP address to the server exceeds the maximum range allowed by 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 calculation of the number of connections may involve more than one terminal user. |
| 422 |
The number of connections from the current client's IP address to the server exceeds the maximum range allowed by 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 calculation of the number of connections may involve more than one terminal user. |
| 422 |
The request is well-formed, but cannot be responded to due to semantic errors. (RFC 4918 WebDAV) 423 Locked
The current resource is locked. (RFC 4918 WebDAV) |
| 424 |
The current request failed due to an error in a previous request, such as PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Defined in the WebDav Advanced Collections draft, but not in the WebDAV Sequenced Sets Protocol (RFC 3658). |
| 426 |
The client should switch to TLS/1.0. (RFC 2817) |
| 449 |
Extended by Microsoft, indicating that the request should be retried after performing appropriate actions. |
| 500 |
The server encountered an unexpected condition that prevented it from completing the request. Generally, this problem occurs when there is an error in the server's program code. |
| 501 |
The server does not support a feature required by the current request. When the server does not recognize the request method and cannot support its request for any resource. |
| 502 |
The server, acting as a gateway or proxy, received an invalid response from an upstream server while attempting to fulfill the request. |
| 503 |
The server is currently unable to process the request due to temporary server maintenance or overload. This condition is temporary and will recover after some time. If the delay can be expected, the response can include a Retry-After header to indicate this delay. If this Retry-After information is not given, the client SHOULD handle it in the same way as 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 refuse the client's connection. |
| 504 |
The server, acting as a gateway or proxy, failed to receive a response from an upstream server (the server identified by the URI, such as HTTP, FTP, LDAP) or a secondary server (such as DNS) in a timely manner while attempting to fulfill the request.
Note: Some proxy servers return 400 or 500 errors when the DNS query times out. |
| 505 |
The server does not support, or refuses to support, the HTTP version used in the request. This implies that the server cannot or is unwilling to use the same version as the client. The response SHOULD include an entity describing why the version is not supported and what protocols the server supports. |
| 506 |
Extended by the Transparent Content Negotiation Protocol (RFC 2295), indicating an internal configuration error on the server: the requested negotiation argument resource is configured to use itself in transparent content negotiation and is therefore not an appropriate focus in a negotiation process. |
| 507 |
The server is unable to store the content necessary to fulfill the request. This condition is considered temporary. WebDAV (RFC 4918) |
| 509 |
The server reached bandwidth limits. This is not an official status code, but is still widely used. |
| 510 |
The policy required to obtain the resource is not satisfied. (RFC 2774) |
