| HTTP Status Code |
Description |
| 100 |
The client should continue sending the request. This temporary response is used to inform the client that part of its request has been received by the server and has not been rejected. The client should continue sending the remainder of the request or ignore this response if the request has already been completed. The server must send a final response after the request is completed. |
| 101 |
The server understands the client's request and will use the Upgrade header to notify the client to switch to a different protocol to complete the request. After sending the final blank line of this response, the server will switch to the protocol defined in the Upgrade header. This should only be done when switching to a new protocol offers significant benefits, such as switching to a new HTTP version or a synchronous protocol for real-time communication. |
| 102 |
Status code extended by WebDAV (RFC 2518), indicating that processing will continue. |
| 200 |
The request was successful, and the requested headers or data body will be returned with this response. |
| 201 |
The request was fulfilled, and a new resource has been created based on the request. Its URI is returned in the Location header. If the resource cannot be created promptly, a '202 Accepted' should be returned. |
| 202 |
The server has accepted the request but has not yet processed it. As the request may still be rejected, there is no guarantee it will be executed. In cases of asynchronous operations, returning this status code is the most convenient method. The 202 response indicates that the server has accepted the request for processing and should include information about the processing status or a pointer to track or estimate whether the operation is complete. |
| 203 |
The server successfully processed the request, but the returned entity header is not from the original server. Instead, it is a copy from a local or third-party source. The information may be a subset or superset of the original. For example, metadata about the resource may cause the original server to know a superset of metadata. Use of this status code is optional and only appropriate when a response would otherwise return a 200 OK status. |
| 204 |
The server successfully processed the request but does not need to return any entity content, though it may return updated metadata. If such metadata exists, it should correspond to the requested variable. If the client is a browser, it should retain the page that made the request without altering the document view. Since a 204 response cannot contain a message body, it always ends with the first empty line after the headers. |
| 205 |
The server successfully processed the request, but unlike the 204 response, this response requires the client to reset the document view. This is primarily used after accepting user input and immediately resetting the form, allowing the user to start again. As with the 204 response, the 205 response must not contain any message body and ends with the first empty line after the headers. |
| 206 |
The server successfully processed a partial GET request. HTTP download tools like FlashGet or Thunder often use this type of response to implement resumable downloads or divide large documents into multiple segments for simultaneous download. The request must include a Range header indicating the desired content range and may include an If-Range condition. The response must include a Content-Range header indicating the range of content returned. If the content type is multipart/byteranges, each multipart segment should include a Content-Range header to indicate the range of content in that segment. If the response includes Content-Length, its value must match the actual byte count of the returned range. Other headers such as Date, ETag, and/or Content-Location should be included if the same request would have returned a 200 response. If the If-Range header was used for strong cache validation, the 206 response must not include other entity headers. Otherwise, the 206 response should contain all entity headers that would have been returned in a 200 response. |
| 207 |
Status code extended by WebDAV (RFC 2518), indicating that the subsequent message body will be an XML message containing a series of individual response codes, depending on the number of sub-requests. |
| 300 |
The requested resource has multiple possible responses, each with its specific address and browser-driven negotiation information. The user or browser can choose one of these options for redirection. Unless this is a HEAD request, the response should include an entity listing the resource characteristics and addresses to assist the user or browser in selecting the appropriate redirection. The entity format is determined by the Content-Type header. If the server already has a preferred response, it should indicate this in the Location header, which the browser may use as the automatic redirection address. |
| 301 |
The requested resource has been permanently moved to a new location, and any future references to this resource should use one of the returned URIs. If possible, clients with link editing capabilities should automatically update the address to the one provided by the server. Unless otherwise specified, this response is cacheable. The new permanent URI should be returned in the Location field of the response. Unless this is a HEAD request, the response body should contain a hyperlink to the new URI and a short description. If this is not a GET or HEAD request, browsers should not automatically redirect unless the user confirms, as the conditions of the request may change. Note: For some browsers using the HTTP/1.0 protocol, when they receive a 301 response to a POST request, the subsequent redirect request will be made as a GET request. |
| 302 |
The requested resource is temporarily available at a different URI. Since this redirection is temporary, the client should continue to send future requests to the original address. This response is only cacheable if specified in Cache-Control or Expires headers. The new temporary URI should be returned in the Location field of the response. Unless this is a HEAD request, the response body should contain a hyperlink to the new URI and a short description. If this is not a GET or HEAD request, the browser should not automatically redirect without user confirmation, as the conditions of the request may change. Note: Although the RFC 1945 and RFC 2068 specifications do not allow clients to change the request method during redirection, many browsers treat the 302 response as a 303 response and use the GET method to access the URI specified in the Location header, regardless of the original request method. Status codes 303 and 307 were added to clarify the server’s expected client behavior. |
| 303 |
The response to the current request can be found at another URI, and the client should use the GET method to retrieve that resource. This status is primarily used to redirect the output of POST requests triggered by scripts to a new resource. This new URI is not considered a replacement for the original resource. The 303 response is not cacheable, but the subsequent (redirected) request may be cached. The new URI should be returned in the Location field of the response. Unless this is a HEAD request, the response body should contain a hyperlink to the new URI and a short description. Note: Many pre-HTTP/1.1 browsers do not correctly understand the 303 status. If compatibility with these browsers is necessary, the 302 status code can be used, as most browsers handle 302 responses in a way consistent with the 303 specification. |
| 304 |
If the client has made a conditional GET request and the request has been allowed, but the document has not changed (since the last visit or based on the request's conditions), the server should return this status code. The 304 response must not contain a message body and always ends with the first empty line after the headers. This response must include the following headers: Date (unless the server does not have a clock). If the server does not have a clock and follows these rules, proxy servers and clients can add the Date field to the received response header (as specified in RFC 2068), ensuring caching works properly. ETag and/or Content-Location headers should be included if the same request would have returned a 200 response. Expires, Cache-Control, and/or Vary headers should be included if their values differ from the corresponding values in other responses for the same variables. If this response used strong cache validation, no other entity headers should be included. Otherwise, if a conditional GET request used weak cache validation, no other entity headers should be included, preventing inconsistencies between cached content and updated entity headers. If a 304 response indicates that an entity is not cached, the caching system must ignore this response and resend the request without any conditions. If a 304 response is received to update a cache entry, the caching 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 proxy specified. The Location field will provide the URI of the designated proxy. The recipient must resend the request through the proxy to access the resource. Only the original server can establish a 305 response. Note: RFC 2068 does not clarify that the 305 response is intended for redirecting a single request and should only be created by the original server. Ignoring these restrictions may have serious security consequences. |
| 306 |
This status code is no longer used in the latest specification. |
| 307 |
The requested resource is temporarily available at a different URI. Since this redirection is temporary, the client should continue sending future requests to the original address. This response is only cacheable if specified in Cache-Control or Expires headers. The new temporary URI should be returned in the Location field of the response. Unless this is a HEAD request, the response body should contain a hyperlink to the new URI and a short description. Since some browsers do not recognize the 307 response, these necessary details should be added to help users understand and access the new URI. If this is not a GET or HEAD request, the browser should not automatically redirect without user confirmation, as the conditions of the request may change. |
| 400 |
1. The request has semantic errors and cannot be understood by the server. The client should not repeat the request without modifications. 2. The request has invalid parameters. |
| 401 |
The current request requires user authentication. The response must include a WWW-Authenticate header suitable for the requested resource to prompt for user credentials. The client may repeat the request with an appropriate Authorization header. If the request already includes Authorization credentials, a 401 response indicates that those credentials were rejected. If the 401 response includes the same authentication request as the previous response, and the browser has already attempted authentication, the browser should display the response's entity body to the user, as it may contain diagnostic information. See RFC 2617. |
| 402 |
This status code is reserved for future use. |
| 403 |
The server understands the request but refuses to authorize it. Unlike a 401 response, authentication will not help, and the request should not be repeated. If this is not a HEAD request and the server wishes to explain why the request was refused, the reason should be included in the entity body. Of course, the server may return a 404 response if it does not wish to provide this information. |
| 404 |
The request failed because the resource could not be found on the server. There is no indication whether this condition is temporary or permanent. If the server knows the situation, it should use the 410 status code to indicate that the resource has been permanently removed and has no forwarding address due to some internal configuration. The 404 status code is widely used when the server does not want to reveal why the request was rejected or when no suitable response is available. |
| 405 | The method specified in the request line cannot be used for the requested resource. This response must return an Allow header listing the methods that are supported by the resource. Since PUT and DELETE methods modify server resources, most web servers either don't support or disallow these methods by default, returning a 405 error for such requests. |
| 406 | The content characteristics of the requested resource cannot satisfy the conditions specified in the request headers, so the server cannot generate a response. Unless it's a HEAD request, this response should include an entity containing information that allows the user or browser to select a more suitable resource. The format of the entity is determined by the media type defined in the Content-Type header. Browsers may automatically select the best option based on this format and their capabilities, though no specific criteria for such automatic selection is defined in the standard. |
| 407 | Similar to the 401 response, but the client must authenticate itself with the proxy. The proxy server must return a Proxy-Authenticate header for identity verification. The client can return a Proxy-Authorization header for authentication. See RFC 2617. |
| 408 | Request Timeout. The client did not complete sending a request within the server's expected time. The client may repeat the request without modification at any time. |
| 409 | The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where the user might be able to resolve the conflict and resubmit the request. The response should include enough information for the user to identify the source of the conflict. Conflicts typically occur during the processing of PUT requests. For example, in version-controlled environments, a 409 error might occur when a PUT request includes version information that conflicts with an earlier request, and the server would return this error to inform the user that the request cannot be completed. The response body may include the differences between the conflicting versions to help the user resubmit a merged version. |
| 410 | The requested resource is no longer available on the server and no forwarding address is known. This condition is considered permanent. If possible, clients with link-editing capabilities should delete any references to this URL after user approval. If the server is unsure whether this condition is permanent, it should return a 404 status code. Unless stated otherwise, this response is cacheable. The purpose of the 410 response is to assist website administrators in maintaining their sites and notifying users that the resource is no longer available and that the server owner intends for all remote links to this resource to be removed. This status code is commonly used in limited-time services or content expiration. Similarly, it is used to notify clients that personal resources on the server are no longer available. Whether all permanently unavailable resources should be marked as '410 Gone' and how long to maintain this mark is up to the server owner. |
| 411 | The server refuses to accept the request without a defined Content-Length header. The client may resubmit the request after adding a valid Content-Length header indicating the size of the request body. |
| 412 | The server did not meet one or more of the preconditions specified in the request headers. This status code allows the client to set preconditions in the request headers' metadata to ensure the request is only applied to the desired resource. |
| 413 | The server refuses to process the current request because the size of the request entity exceeds what the server is willing or able to handle. The server may close the connection to prevent the client from continuing the request. If the condition is temporary, the server should include a Retry-After header to indicate when the client can try again. |
| 414 | The URI provided in the request is too long for the server to process, so the request is rejected. This is uncommon but can occur in cases such as: a GET request is used for form submission instead of POST, resulting in an overly long query string. Or, there might be a redirect "black hole" where each redirection appends the previous URI as part of the new URI, eventually leading to an excessively long URI. In some cases, this can also be an attack attempt where the client tries to exploit server vulnerabilities by sending a URI that exceeds buffer limits, potentially causing a buffer overflow and allowing arbitrary code execution. Servers without such vulnerabilities should return a 414 status code. |
| 415 | The entity format submitted in the request is not supported by the server for the requested method or resource, so the request is rejected. |
| 416 | If the request includes a Range header and the specified range does not overlap with the available range of the current resource, and if the request did not include an If-Range header, the server should return a 416 status code. If the Range refers to a byte range, this means the starting byte position exceeds the length of the current resource. The server should also return a Content-Range header indicating the current length of the resource. |
| 417 | The expectation given in the Expect header of the request cannot be met by the server, or the server is a proxy that has clear evidence that the next node in the request chain cannot meet the expectation. |
| 421 | The number of connections from the current client's IP address exceeds the server's allowable limit. This IP address typically refers to the client's address seen by the server (e.g., a gateway or proxy address). The number of connections counted may involve more than one end user in this case. |
| 422 | The request was well-formed but could not be followed due to semantic errors. (RFC 4918 WebDAV) |
| 423 | The current resource is locked. (RFC 4918 WebDAV) |
| 424 | The request failed due to an error with a previous request, such as a PROPPATCH request. (RFC 4918 WebDAV) |
| 425 | Defined in the WebDav Advanced Collections draft but not present in the WebDAV Ordered Collections Protocol (RFC 3658). |
| 426 | The client should switch to TLS/1.0. (RFC 2817) |
| 449 | A Microsoft extension, indicating the request should be retried after the client performs the appropriate action. |
| 500 | The server encountered an unexpected condition that prevented it from fulfilling the request. This error generally occurs when there is a problem with the server's code. |
| 501 | The server does not support the functionality required to fulfill the request. This occurs when the server cannot recognize the request method and cannot support it for any resource. |
| 502 | The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed while attempting to fulfill the request. |
| 503 | The server is currently unable to handle the request due to temporary overload or scheduled maintenance. This condition is temporary and will be resolved after some time. If the delay is foreseeable, the response should include a Retry-After header indicating when the service will be restored. If no Retry-After information is provided, the client should handle this response as a 500 status. Note: The existence of a 503 status code does not mean the server must use it when overloaded; some servers may simply reject the connection. |
| 504 | The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server (e.g., HTTP, FTP, LDAP) or auxiliary server (e.g., DNS). Note: Some proxy servers may return a 400 or 500 error when a DNS lookup 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 explaining why the version is unsupported and what protocols the server supports. |
| 506 | Extended by the Transparent Content Negotiation Protocol (RFC 2295), indicating an internal configuration error: the requested negotiable resource is configured to use itself in content negotiation, thus it is not a proper endpoint for negotiation. |
| 507 | The server cannot store the necessary content to complete the request. This condition is considered temporary. (WebDAV, RFC 4918) |
| 509 | The server has reached its bandwidth limit. This is not an official status code but is widely used. |
| 510 | The request cannot be fulfilled because the policy required to access the resource has not been met. (RFC 2774) |