| HTTP Status Code |
Meaning of Status Code |
| 100 |
The client should continue sending the request. This temporary response is used to notify the client that part of its request has been received by the server and has not been rejected yet. The client should continue sending the remaining part of the request, or ignore this response if the request has been completed. The server must send a final response once the request is complete. |
| 101 |
The server has understood the client's request and will notify the client to adopt a different protocol to complete this request via the Upgrade message header. After sending the final empty line of this response, the server will switch to the protocols defined in the Upgrade message header. Such measures should only be taken if switching to new protocols is more beneficial. For example, switching to a new version of HTTP is more advantageous than an old version, or switching to a real-time and synchronous protocol to deliver resources that utilize such features. |
| 102 |
A status code extended by WebDAV (RFC 2518), indicating that processing will continue. |
| 200 |
The request was successful, and the desired response headers or payload will be returned with this response. |
| 201 |
The request has been fulfilled, and a new resource has been created in accordance with the request, with its URI returned in the Location header. If the required resource cannot be created in a timely manner, '202 Accepted' should be returned instead. |
| 202 |
The server has accepted the request but has not yet processed it. Just like it may be rejected, the request may or may not be executed eventually. When it comes to 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 (for example, a batch operation that is executed only once daily) without requiring the client to maintain a connection to the server until the batch operation is complete. In accepting the request for processing and returning a response with a 202 status code, the response should include some information indicating the current status of the processing, as well as pointers to a processing status monitor or prediction, allowing users to estimate whether the operation has been completed. |
| 203 |
The server successfully processed the request, but the returned entity header metadata is not a valid representation from the original server, but rather a copy from local or third-party sources. The current information may be a subset or superset of the original version. For example, metadata that accompanies the resource may lead the original server to know the metadata's super. Using this status code is not mandatory, and is only appropriate in cases where the response would otherwise return 200 OK. |
| 204 |
The server successfully processed the request but does not need to return any entity content and wishes to return updated metadata. The response may return new or updated metadata in the form of entity headers. If these header information exist, they should correspond with the variables requested. If the client is a browser, then the user’s browser should keep the page that sent the request and should not produce any changes in the document view, even though according to standards, the new or updated metadata should be applied to the document in the user’s browser active view. Since the 204 response is prohibited from including any message body, it always ends with the first empty line following the message headers. |
| 205 |
The server successfully processed the request and did not return any content. However, unlike the 204 response, the response with this status code requires the requester to reset the document view. This response is mainly used to reset forms immediately after accepting user input so that users can easily start another input. Like the 204 response, this response is also prohibited from including any message body, and it ends with the first empty line after the message headers. |
| 206 |
The server has successfully processed partial GET requests. HTTP downloading tools like FlashGet or Thunder use this type of response to implement download resume or break a large document into several segments for simultaneous download. The request must contain a Range header to indicate the content range desired by the client, and it may include If-Range as a request condition. The response must include the following header fields: Content-Range to indicate the range of content returned in this response; if it is a multi-part download with Content-Type as multipart/byteranges, each multipart segment must contain a Content-Range field to indicate the content range of that segment. If the response includes Content-Length, its value must match the actual byte count of the content returned. The response may also include a Date ETag and/or Content-Location if the same request was supposed to return a 200 response. Expires, Cache-Control, and/or Vary may have different values from previous responses corresponding to the same variables. If the request for this response uses strong caching validation with If-Range, this response should not include other entity headers; if the request for this response uses weak caching validation with If-Range, this response is prohibited from including any other entity headers; this prevents inconsistencies between cached entity content and updated entity header information. Otherwise, this response should include all the entity header fields that should have been returned in a 200 response. If the ETag or Last-Modified headers do not match accurately, the client cache should not combine the content returned in the 206 response with any previously cached content. Any caches that do not support Range and Content-Range headers are prohibited from caching content returned in the 206 response. |
| 207 |
A status code extended by WebDAV (RFC 2518), indicating that the subsequent message body will be an XML message, which may contain a series of independent response codes depending on the number of previous sub-requests. |
| 300 |
The requested resource has various options for feedback information, each with its specific address and browser-driven advertising information. Users or browsers can select a preferred address to redirect. Unless this is a HEAD request, this response should include an entity listing the resource properties and addresses so that users or browsers can select the most suitable redirection address. The format of this entity is determined by the format defined by the Content-Type. Browsers may make the most suitable choice based on the response format and their own capabilities. Of course, RFC 2616 does not specify how such automatic selection should be carried out. If the server itself already has a preferred feedback option, that URI should be indicated in the Location; browsers may treat this Location value as the address for automatic redirection. Moreover, unless specified otherwise, this response is also cacheable. |
| 301 |
The requested resource has been permanently moved to a new location, and all future references to this resource should use one of the URIs returned in this response. If possible, clients with link editing capabilities should automatically modify the requested address to the address feedback from the server. Unless specified otherwise, 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 entity of the response should contain a hyperlink to the new URI along with a brief description. If this is not a GET or HEAD request, then the browser is prohibited from automatically redirecting unless getting user confirmation, as the conditions of the request might change as a result. Note: For certain browsers using HTTP/1.0 protocol, when a POST request they send receives a 301 response, the subsequent redirect request will turn into a GET method. |
| 302 |
The requested resource is now temporarily responding to the request from a different URI. As this redirection is temporary, the client should continue to send subsequent requests to the original address. This response is only cacheable when 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 along with a brief description. If this is not a GET or HEAD request, the browser is prohibited from automatically redirecting unless it gets user confirmation, as the conditions of the request might change as a result. Note: Although RFC 1945 and RFC 2068 specifications do not allow clients to change the request method on redirection, many existing browsers treat a 302 response as a 303 response and access the URI specified in the Location using the GET method, ignoring the original request method. Status codes 303 and 307 have been added to clarify what type of response the server expects from the client. |
| 303 |
The response corresponding to the current request can be found at another URI, and the client should access that resource using the GET method. This method exists mainly to allow the output of POST requests activated by scripts to redirect to a new resource. This new URI is not an alternative reference to the original resource. Furthermore, 303 responses are prohibited from being cached. Of course, 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 along with a brief description. Note: Many browsers prior to HTTP/1.1 do not interpret the 303 status correctly. If interaction with these browsers is a consideration, the 302 status code should suffice, as most browsers process 302 responses in the manner that the above specification requires clients to process the 303 response. |
| 304 |
If a client sends a conditional GET request that has been permitted and the document content (since the last visit or depending on the conditions of the request) has not changed, the server should return this status code. The 304 response is prohibited from containing a message body, thus always ending with the first empty line following the message headers. This response must contain the following headers: Date unless this server has no clock. If a server without a clock adheres to these rules, then proxy servers and clients can add the Date field to the received response headers (as specified in RFC 2068), and caching mechanisms will work properly. ETag and/or Content-Location if the same request was supposed to return a 200 response. Expires, Cache-Control, and/or Vary if their values might differ from other previous responses corresponding to the same variables. If this response request used strong caching validation, this response should not include other entity headers; otherwise (for example, a conditional GET request using weak caching validation), this response is prohibited from including other entity headers; this prevents inconsistencies between cached entity content and updated entity header information. If a 304 response indicates that a certain entity is not cached, then the caching system must ignore this response and resend a request without limitations. If a 304 response is received that requests an update to a cached entry, the caching system must update the entire entry to reflect all values of fields that were updated in the response. |
| 305 |
The requested resource must be accessed through the specified proxy. The URI information where the specified proxy is located will be provided in the Location field, and the recipient needs to resend a separate request to access the corresponding resource through this proxy. Only the original server can establish a 305 response. Note: RFC 2068 does not explicitly define a 305 response as a way to redirect a separate request and can only be established by the original server. Ignoring these restrictions may lead to serious security consequences. |
| 306 |
The 306 status code is no longer used in the latest specifications. |
| 307 |
The requested resource is now temporarily responding to the request from a different URI. As this redirection is temporary, the client should continue sending subsequent requests to the original address. This response is only cacheable when 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 along with a brief description. Since some browsers may not recognize the 307 response, it is necessary to provide the above-heavy information to allow users to understand and send requests to the new URI. If this is not a GET or HEAD request, the browser is prohibited from automatically redirecting unless it gets user confirmation, as the conditions of the request might change as a result. |
| 400 |
1. The semantic error; the current request cannot be understood by the server. Unless modified, the client should not repeat this request. 2. The request parameters are incorrect. |
| 401 |
The current request requires user validation. This response must contain a WWW-Authenticate information header applicable to the requested resource to prompt for user information. The client can resubmit a request containing the appropriate Authorization header. If the current request already contains the Authorization credentials, then a 401 response indicates that the server has rejected those credentials. If the 401 response contains the same authentication prompt as the previous response and the browser has attempted to authenticate at least once, the browser should present the entity information contained in the response to the user, as this entity information may contain relevant diagnostic information. See RFC 2617. |
| 402 |
This status code is reserved for possible future use. |
| 403 |
The server has understood the request but refused to execute it. Unlike the 401 response, authentication offers no help, and this request should not be repeated. If this is not a HEAD request, and the server wishes to explain why the request cannot be executed, it should describe the reason for refusal in the entity. Of course, the server can also return a 404 response if it does not wish the client to gain any information. |
| 404 |
The request failed, and the resource requested could not be found on the server. There is no information to tell the user whether this situation is temporary or permanent. If the server knows, it should use the 410 status code to inform that the old resource is no longer available due to some internal configuration mechanism, and there is no redirection address. The 404 status code is widely used when the server does not want to disclose why the request was refused or when no other suitable response is available. |
| 405 |
The request method specified in the request line is not allowed for the resource that is being requested. This response must return an Allow header indicating the list of request methods that are acceptable for the current resource. Given that PUT and DELETE methods can perform write operations on resources on the server, most web servers do not support or allow those request methods in the default configuration, and will return a 405 error for such requests. |
| 406 |
The content characteristics of the requested resource do not satisfy the conditions in the request headers; therefore, the response entity cannot be generated. Unless this is a HEAD request, this response should return an entity containing a list of addresses and content characteristics that allow users or browsers to select the most suitable entity properties. The format of the entity is determined by the media type defined in the Content-Type header. Browsers can make their best choice based on the format and their capabilities. However, the specification does not define any standards for making such automatic selections. |
| 407 |
Similar to the 401 response, except that the client must authenticate with the proxy server. The proxy server must return a Proxy-Authenticate header for authentication inquires. The client may return a Proxy-Authorization information header to verify. See RFC 2617. |
| 408 |
Request timeout. The client failed to complete sending a request within the time that the server was prepared to wait. The client may resubmit this request at any time without making any changes. |
| 409 |
The request cannot be completed due to a conflict with the current state of the requested resource. This code is only allowed to be used in cases where the user is thought to be able to resolve the conflict and will resubmit a new request. The response should contain sufficient information for the user to discover the source of the conflict. Conflicts usually arise during the processing of PUT requests. For instance, in an environment that employs version checks, a modification request for a specific resource made via a PUT submission may conflict with information regarding a previous (third-party) request; in this case, the server should return a 409 error to inform the user that the request cannot be completed; the response entity may likely contain a comparison of differences between the two conflicting versions to allow the user to resubmit a new combined version. |
| 410 |
The requested resource is no longer available on the server and there is no forwarding address known. This situation should be regarded as permanent. If possible, clients with link editing capabilities should delete any references to this address after obtaining user permission. If the server does not know or cannot determine whether this situation is permanent, it should use the 404 status code. Unless stated otherwise, this response is cacheable. The purpose of the 410 response is mainly to assist website administrators in maintaining the site, informing users that the resource is no longer available, and indicating that the server's owner wishes to have all remote connections to this resource deleted. Such events are commonplace in limited-time, value-added services. The 410 response is also used to inform clients that a resource which originally belonged to an individual is no longer available on the current server site. Of course, whether all permanently unavailable resources should be marked as '410 Gone' and how long such marking should be maintained is entirely up to the server owner. |
| 411 |
The server refuses to accept the request without a defined Content-Length header. The client can resubmit this request 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 specified in the request's header fields. This status code allows the client to set preconditions in the request metadata (request header data) when acquiring resources, so as to prevent that request method from being applied to resources other than the desired content. |
| 413 |
The server refuses to process the current request because the entity data size submitted by the request exceeds the range that the server is willing or able to process. In this situation, the server may close the connection to prevent the client from continuing to send this request. If this situation is temporary, the server should return a Retry-After response header to inform the client when to try again. |
| 414 |
The length of the requested URI exceeds the length that the server is able to interpret, and therefore the server refuses to provide service for that request. This is quite rare; common situations include: a form submission that should use the POST method becoming a GET method, resulting in an excessively long query string; redirect URI "black holes," where every redirection uses the old URI as part of the new URI, leading to an excessively long URI after several redirects; a client attempting to exploit vulnerabilities existing in certain servers. Such servers use fixed-length buffers to read or manipulate the request's URI, and when the parameters after GET exceed a certain value, a buffer overflow may occur, leading to arbitrary code execution. Servers that do not have such vulnerabilities should return the 414 status code. |
| 415 |
The entity submitted in the request is in a format not supported by the server for the method and requested resource, hence the request is rejected. |
| 416 |
If the request contains a Range request header, and any data ranges specified in the Range do not overlap with the current resource's available ranges, while the request does not define an If-Range request header, then the server should return a 416 status code. If the Range used is in bytes, this indicates that the first byte position of the requested data range exceeds the current resource's length. The server should also include a Content-Range entity header indicating the current resource's length when returning the 416 status code. This response is also prohibited from using multipart/byteranges as its Content-Type. |
| 417 |
The expectation specified in the Expect request header could not be satisfied by the server, or the server is a proxy that has clear evidence that the Expect content cannot be satisfied at the next node in the current route. |
| 421 |
The number of connections from the current client's IP address to the server has exceeded the maximum limit allowed by the server. Typically, this IP address refers to the client address seen from the server (such as a user's gateway or proxy server address). In this case, the counting of connection numbers may involve more than one end user. |
| 422 |
The request format is correct 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 that occurred with a previous request, such as PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
This status code is defined in the WebDav Advanced Collections draft but does not appear in the "WebDAV Ordered Collections Protocol" (RFC 3658). |
| 426 |
The client should switch to TLS/1.0. (RFC 2817) |
| 449 |
An extension by Microsoft indicating that the request should be retried after performing the appropriate action. |
| 500 |
The server encountered an unexpected condition that prevented it from fulfilling the request. Generally, this problem arises when there is an error in the server's code. |
| 501 |
The server does not support a feature required by the current request. This occurs when the server cannot recognize the method of the request and is unable to support requests to any resource. |
| 502 |
A server working as a gateway or proxy received an invalid response when trying to process the request from the upstream server. |
| 503 |
The server is currently unable to process the request due to temporary maintenance or overload. This situation is temporary and is expected to recover after some time. If the delay time can be anticipated, the response may include a Retry-After header to indicate this delay time. If no Retry-After information is provided, 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 servers must use it during overload situations. Some servers simply prefer to deny the client's connection. |
| 504 |
A server working as a gateway or proxy failed to receive a timely response from the upstream server (the server identified by the URI, e.g., HTTP, FTP, LDAP) or auxiliary server (e.g., DNS) while attempting to process the request. Note: Some proxy servers may return a 400 or 500 error during a DNS query timeout. |
| 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 which protocols the server supports. |
| 506 |
Extended by the "Transparent Content Negotiation Protocol" (RFC 2295), indicating that the server has a misconfiguration: the requested negotiation variant resource is configured to use itself in transparent content negotiation, thereby making it an unsuitable focal point in a negotiation process. |
| 507 |
The server cannot store the content necessary to complete the request. This condition is considered temporary. WebDAV (RFC 4918) |
| 509 |
The server has reached the bandwidth limit. This is not an official status code but is still widely used. |
| 510 |
The policy required to obtain the resource has not been met. (RFC 2774) |