| HTTP Status Code | Description |
|---|
| 100 | The client should continue with its request. This temporary response is used to notify the client that part of the 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 is already complete. The server must send a final response after the request is completed. |
| 101 | The server understands and is willing to comply with the client's request, via the Upgrade header field, for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the Upgrade header field immediately after the empty line that terminates the 101 response. The server should only switch protocols when it is advantageous to do so. For example, switching to a newer version of HTTP might be more efficient, or switching to a real-time and synchronous protocol might be needed to deliver resources that use such features. |
| 102 | Extended status code by WebDAV (RFC 2518), indicating that processing will continue. |
| 200 | The request has succeeded, and the desired response header or body data will be returned with this response. |
| 201 | The request has been fulfilled, and a new resource has been created as per the client's request, with its URI returned in the Location header field. If the necessary resource cannot be created promptly, a '202 Accepted' response should be returned. |
| 202 | The server has accepted the request but has not yet processed it. This status code is intended for cases where another process or server handles the request, or where processing occurs asynchronously. The response should include an indication of the request's current status and pointers to a status monitor or status prediction. |
| 203 | The server has successfully processed the request, but the returned entity header is from a local or third-party copy, not the origin server. The current information might be a subset or superset of the original version. Using this status code is not mandatory, and it is appropriate only when the response without this status code would be '200 OK'. |
| 204 | The server has successfully processed the request, but is not returning any content. The response may contain updated meta-information in the form of entity headers. If there are entity headers, they should be associated with the requested variable. If the client is a browser, the user agent should retain the page that sent the request without any changes to the document view, even if the updated meta-information should be applied. Since a 204 response is forbidden to contain any message body, it is always terminated by the first empty line after the header fields. |
| 205 | The server has successfully processed the request, and there is no additional content to send in the response payload body. However, unlike a 204 response, this response requires that the requester reset the document view. This response is primarily intended to facilitate input from the user after submission of a form, so that the user can easily start another input. Like a 204 response, this response is forbidden to contain any message body and is always terminated by the first empty line after the header fields. |
| 206 | The server has successfully fulfilled a partial GET request. HTTP download tools such as FlashGet or Thunder use this type of response to implement resuming downloads or splitting a large file into smaller parts for simultaneous download. The request must include a Range header field to specify the desired range, and may also include an If-Range header field to make the request conditional. The response must contain a Content-Range header field indicating the range of the content being returned. If it is a multi-part download with Content-Type of multipart/byteranges, each part should contain a Content-Range field to specify the range of the part. If the response contains a Content-Length header, its value must match the actual number of bytes returned. The Date, ETag, and/or Content-Location headers, if applicable, should match the values that would have been returned with a '200 OK' response. The Expires, Cache-Control, and/or Vary headers may differ from the values in previous responses. If the request was made with strong cache validation, the response must not include any other entity headers. If weak cache validation was used, the response must not include other entity headers to avoid inconsistencies between cached entity content and updated entity header information. |
| 207 | Extended status code by WebDAV (RFC 2518), indicating that subsequent message bodies will be an XML message and may contain a series of separate response codes depending on the number of previous sub-requests. |
| 300 | The requested resource corresponds to any one of a set of representations, each with its own specific location, and may be negotiated by the user or user agent. Unless this is a HEAD request, the response should include a list of resource characteristics and locations from which the user or user agent can choose the most appropriate redirect address. The format of this entity is defined by the media type specified in the Content-Type header field. Browsers may automatically select the most appropriate option based on the format and capabilities of the browser, although RFC 2616 does not specify how this automatic selection should occur. If the server already has a preferred choice, it should include the URI of that choice in the Location field; the user agent may use the value of the Location field for automatic redirection. Unless otherwise specified, this response is 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 returned URIs. If possible, the client should automatically update the request's address to the new URI 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 with a brief explanation. If this is not a GET or HEAD request, the client must not automatically redirect unless it obtains user confirmation, as the request's conditions may change as a result. |
| 302 | The requested resource is temporarily available at a different URI. Since such a redirect is temporary, the client should continue to use the original request URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field. 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 with a brief explanation. If this is not a GET or HEAD request, the client must not automatically redirect unless it obtains user confirmation, as the request's conditions may change as a result. |
| 303 | The response to the current request can be found at another URI, and the client should use the GET method to retrieve it. This method is primarily used to allow the output of a POST-activated script to redirect the user agent to a new resource. The new URI is not a substitute reference for the original resource. Also, a 303 response must not be cached. However, the second (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 with a brief explanation. Note: Many HTTP/1.1 version browsers do not correctly understand a 303 status. If you need to consider compatibility with these browsers, the 302 status code may suffice since most browsers handle 302 responses in a manner similar to what the specification requires of clients in processing a 303 response. |
| 304 | If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server should return this status code. The 304 response must not contain a message body, and is always terminated by the first empty line after the header fields. The response must include the following header fields: Date, unless the server does not have a clock. If a server without a clock obeys these rules, proxies and clients can add the Date field to received responses (as specified in RFC 2068), and cache mechanisms will work correctly. ETag and/or Content-Location, if the same request would have resulted in a '200 OK' response. Expires, Cache-Control, and/or Vary, if the field values might differ from previous responses corresponding to the same variable. If a strong cache validator is used, this response must not include any other entity headers; otherwise (e.g., if a weak cache validator is used), this response must not include any other entity headers to avoid inconsistencies between cached entity content and updated entity headers. If a 304 response indicates that the current entity is not cached, the cache must ignore this response and repeat the request without any conditions. If a 304 response is received to update a cached entry, the cache must update the entire entry to reflect all of the field values updated in the response. |
| 305 | The requested resource must be accessed through the proxy specified in the Location field. The recipient needs to repeat the request via the proxy to access the resource. Only the original server can create a 305 response. Note: RFC 2068 does not clearly define that a 305 response is meant to redirect a single request and must only be created by the original server. Ignoring these restrictions could lead to serious security consequences. |
| 306 | The 306 status code is no longer in use. |
| 307 | The requested resource is temporarily available at a different URI. Since this redirect is temporary, the client should continue using the original request URI for future requests. The response is only cacheable if specified by a Cache-Control or Expires header field. 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 with a brief explanation. Because some browsers do not recognize a 307 response, it is necessary to provide the necessary information so that users can understand and access the new URI. If this is not a GET or HEAD request, the client must not automatically redirect unless it obtains user confirmation, as the request's conditions may change as a result. |
| 400 | 1. The server cannot understand the request due to incorrect syntax. Unless modified, the client should not repeat the request. 2. The request parameters are incorrect. |
| 401 | The current request requires user authentication. The response must include a WWW-Authenticate header field applicable to the requested resource to prompt user credentials. The client can repeat the request with a suitable Authorization header field. If the current request already includes an Authorization certificate, the 401 response indicates that the server has rejected that certificate. If the 401 response contains the same authentication challenge as before, and the browser has already attempted authentication at least once, the browser should display the entity information contained in the response because it may contain relevant 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 wants to explain why the request was not fulfilled, it should include the reason in the entity. Of course, the server can also return a 404 response if it does not want to disclose any information. |
| 404 | The server cannot find the requested resource. This response does not indicate whether the condition is temporary or permanent. If the server knows the situation, it should use a 410 status code to indicate that the old resource is permanently unavailable due to an internal configuration problem and there is no forwarding address. The 404 status code is widely used when the server does not want to reveal why the request was denied or when no other response is appropriate. |
| 405 | The request method specified in the request-line cannot be used for the requested resource. The response must return an Allow header field listing the methods that the current resource supports. Since the PUT and DELETE methods write operations on resources, most web servers do not support or allow these methods by default, returning a 405 error for such requests. |
| 406 | The requested resource is only capable of generating content that is not acceptable according to the Accept headers sent in the request. Unless this is a HEAD request, the response should return an entity containing a list of resource characteristics and locations from which the user or user agent can choose the most appropriate one. The format of this entity is defined by the media type given in the Content-Type header field. Browsers can make the best choice based on the format and their capabilities. However, the specification does not define any standards for making such automatic selections. |
| 407 | This is similar to a 401 response, but the client must authenticate itself to the proxy. The proxy must return a Proxy-Authenticate header field to prompt for credentials. The client can return a Proxy-Authorization header field to authenticate itself. See RFC 2617. |
| 408 | The server timed out waiting for the request. The client did not produce a request within the time that the server was prepared to wait. The client may repeat the request without modifications 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 contain enough information to allow the user to discover the conflict's source. Conflicts are most likely to occur in response to a PUT request. For example, in a version-controlled environment, a PUT request might conflict with previous changes to a resource made by another user, in which case the server should return a 409 error to indicate that the request cannot be completed. The response entity is likely to contain a comparison between the conflicting versions so that the user can resubmit a new version after merging. |
| 410 | The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. If possible, clients with link editing capabilities should delete references to the requested resource after user approval. If the server does not know or has no way to determine whether this condition is permanent, the 404 status code should be used instead. Unless otherwise specified, this response is cacheable. The 410 response is primarily intended to help webmasters maintain their sites, notify users that the resource is no longer available, and indicate that the server owners want all remote links to that resource removed. Such events are common in time-limited promotional services. Similarly, the 410 response can be used to notify the client that the resource formerly associated with an individual at the server site is no longer available. However, whether to mark all permanently unavailable resources as '410 Gone' and how long to keep this mark is entirely at the server owner's discretion. |
| 411 | The server refuses to accept the request without a defined Content-Length header. After adding a valid Content-Length header indicating the length of the request message body, the client may retry the request. |
| 412 | The server does not meet one or more preconditions specified in the request headers. This status code allows the client to set preconditions in the request headers to avoid applying the request method to a resource other than the intended one. |
| 413 | The server refuses to process the request because the request payload is too large for the server to handle. The server may close the connection to prevent the client from continuing the request. If the condition is temporary, the server should return a Retry-After header to indicate when the client can retry the request. |
| 414 | The request URI is too long for the server to interpret. This rare situation typically occurs in cases such as: form submissions that should have used the POST method are sent as GET, resulting in an overly long query string; redirect URI "black holes," where each redirect adds a portion of the old URI as part of the new URI, causing an overly long URI after several redirects; the client is attempting to exploit a server security vulnerability. Servers without such vulnerabilities should return a 414 status code. |
| 415 | The server refuses to accept the request because the payload format is not supported by the target resource for the requested method. |
| 416 | If a request includes a Range header, and none of the specified ranges are valid for the current resource, and the request did not include an If-Range header, the server should return a 416 status code. If the Range is byte-based, this means that all requested ranges' first bytes exceed the current resource's length. The server should also include a Content-Range header in the 416 response to indicate the current resource's length. This response must not use 'multipart/byteranges' as its Content-Type. |
| 417 | The expectation given in the request's Expect header could not be met by the server, or the server is a proxy that has clear evidence that the next-hop server could not meet the request's expectation. |
| 421 | The number of connections from the client's current IP address to the server exceeds the server's allowable maximum. This typically refers to the client's IP address as seen by the server (such as the user's gateway or proxy address). In this case, the number of connections may involve more than one end-user. |
| 422 | The request was well-formed but was unable to be followed due to semantic errors. (RFC 4918 WebDAV) 423 Locked. The current resource is locked. (RFC 4918 WebDAV) |
| 424 | The request failed due to a failure of a previous request, such as PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Defined in the WebDav Advanced Collections draft but not present in "WebDAV Ordered Collections 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 appropriate actions are taken. |
| 500 | The server encountered an unexpected condition that prevented it from fulfilling the request. Generally, this problem appears when the server's code is incorrect. |
| 501 | The server does not support the functionality required to fulfill the request. The server cannot recognize the request method and is unable to support any resources' requests. |
| 502 | The server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request. |
| 503 | Due to temporary overloading or maintenance, the server is currently unable to handle the request. This situation is temporary and will be resolved after some time. If the delay time is known, the response may include a Retry-After header to indicate this delay. If no Retry-After information is provided, the client should treat it as a 500 response. Note: The existence of a 503 status code does not mean that the server must use it when it is overloaded. Some servers simply wish to deny client connections. |
| 504 | The server, while acting as a gateway or proxy, did not receive a timely response from an upstream server (the URI specified in the request, such as HTTP, FTP, LDAP) or auxiliary server (e.g., DNS). Note: Some proxy servers may return a 400 or 500 error in the event of a DNS query timeout. |
| 505 | The server does not support or refuses to support the HTTP protocol version that was used in the request message. This implies that the server is not willing to use the same version of the protocol as the client. The response should include an entity describing why that version is not supported and what protocols are supported by the server. |
| 506 | Extended by the "Transparent Content Negotiation Protocol" (RFC 2295), indicating that the server has an internal configuration error: the requested negotiable resource is configured to use itself in transparent content negotiation, making it not a suitable endpoint in a negotiation process. |
| 507 | The server is unable to store the representation needed to complete the request. This condition is considered temporary. (WebDAV RFC 4918) |
| 509 | The server has exceeded the bandwidth limit. This is not an official status code but is still widely used. |
| 510 | The policy required to get the resource has not been met. (RFC 2774) |