| HTTP Status Code |
Status Code Meaning |
| 100 |
The client should continue to send the request. This is an interim response to inform the client that part of its request has been received by the server and has not been rejected. The client should continue to send the remaining part of the request or, if the request is already complete, ignore this response. The server must send a final response to the client after the request has been completed. |
| 101 |
The server has understood the client's request and will complete it by switching to a different protocol, as notified by the Upgrade header field. After sending the empty line that terminates the 101 response, the server will switch to the new protocol specified in the Upgrade header field. This mechanism is useful only when switching to a new protocol which is actually better than the old one. For example, switching to a new version of HTTP is advantageous over older versions or switching to a real-time, synchronous protocol might be beneficial for the resource being requested. |
| 102 |
A status code extension from WebDAV (RFC 2518), indicating that the processing will continue. |
| 200 |
The request has succeeded, and the requested headers or data will be returned with this response. |
| 201 |
The request has been fulfilled and resulted in a new resource being created. The newly created resource's URI has been returned in the Location header field. If the resource could not be created immediately, a '202 Accepted' status should be returned instead. |
| 202 |
The request has been accepted for processing, but the processing has not been completed. The request may or may not eventually be acted upon, as it may be disallowed when processing occurs. In the case of an asynchronous operation, there is no facility for immediately returning an indication of whether the request has been successfully processed. Instead, the server returns a 202 status code to indicate that the request has been accepted for processing, but the processing has not been completed. The response should include an indication of the current status of the request and a pointer to a status monitor or an estimate of when the request will be completed. This allows the server to accept a request for some other process (e.g., a batch-oriented operation that is executed once a day) without requiring that the user agent's connection to the server persist until the process is completed. |
| 203 |
The server has successfully processed the request, but the returned entity-header fields are not the definitive set as available from the origin server, but are a copy as seen by a locally or third-party intermediary. This is being done in either or both of the following cases: (1) as a result of using a cache to save access time to the origin server, or (2) to transform the data through some other form of intermediary processing. If the intermediary has modified the content of the response, it may add appropriate Warning headers (as defined in RFC 2616 section 14.46) to provide information about the modification. If the response is a 3xx redirection, the Location header must be modified to point to the actual location of the resource as seen by the intermediary. The 203 response is inherently unstable and may be updated by the origin server or by the intermediary to a different representation over time. If the client is a user agent, it should not change its document view from that which caused the request to be sent. This response is only cacheable if indicated by a Cache-Control or Expires header field. |
| 204 |
The server has successfully processed the request, but is not returning any content. Instead, the status line and header fields indicate where the new or updated meta-information for the resource is to be found. If the client is a user-agent, it should not change its document view from that which caused the request to be sent. This response is particularly useful for operations that do not result in a resource being created or modified but still might want to return updated meta-information. If the new or updated meta-information is small in size, it is practical to return it in the header field. If the meta-information is too large to fit into the header, it could be returned as an entity-body. However, since the 204 response is intended to confirm that the request has been successfully processed, it must not include an entity-body, and thus is always terminated by the first empty line after the header fields. |
| 205 |
The server has successfully processed the request and is not returning any content. However, unlike a 204 response, this response requires the requester to reset the document view. This response is primarily used to reset the form immediately after accepting user input, allowing users to easily start another input. Like a 204 response, this response is also prohibited from containing any message body and ends with the first empty line after the headers. |
| 206 |
The server has successfully processed a partial GET request. HTTP download tools like FlashGet or Thunder use this type of response to enable resume capabilities or divide a large document into multiple segments for simultaneous download. The request must include a Range header to indicate the desired range of content from the client and may include If-Range as a conditional request. The response must include the following header fields: Content-Range to indicate the range of content returned in this response; if the Content-Type is multipart/byteranges for multi-segment downloads, each multipart segment should include 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 returned content range. Date, ETag, and/or Content-Location, if the same request would otherwise return a 200 response. Expires, Cache-Control, and/or Vary, if their values may differ from those in other responses for the same variant. If the request used If-Range with strong cache validation, the response should not include other entity-headers; if the request used If-Range with weak cache validation, the response must not include other entity-headers; this avoids inconsistency between the cached entity-body and the updated entity-headers. Otherwise, the response should include all entity-headers that would be returned in a 200 response. If the ETag or Last-Modified header does not match exactly, the client cache should not combine the content returned by a 206 response with any previously cached content. Any cache that does not support Range and Content-Range headers must not cache the content returned by a 206 response. |
| 207 |
A status code extended by WebDAV (RFC 2518), indicating that the subsequent message body will be an XML message and may contain a series of individual response codes, depending on the number of previous sub-requests. |
| 300 |
The requested resource has multiple representations, each with its own specific location and browser-driven negotiation information. The user or browser can select a preferred address for redirection. Unless it is a HEAD request, the response should include an entity with a list of resource characteristics and addresses, allowing the user or browser to choose 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 suitable choice based on the response format and its own capabilities. However, RFC 2616 does not specify how such automatic selection should be performed. If the server has a preferred representation, it should indicate the URI of this representation in the Location field; the browser may use this Location value as the address for automatic redirection. Additionally, unless specified otherwise, this response is cacheable. |
| 301 |
The requested resource has been moved to a new permanent URI, and 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 change the request address to the address fed back 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 it is a HEAD request, the response entity should include a hyperlink to the new URI and a brief explanation. If it is not a GET or HEAD request, browsers are prohibited from automatically redirecting unless confirmed by the user, as the request conditions may have changed. Note: For some browsers using HTTP/1.0, when they send a POST request and receive a 301 response, the subsequent redirect request will become a GET request. |
| 302 |
The requested resource is temporarily responding from a different URI. Since this redirection is temporary, clients should continue to send future requests to the original address. This response is cacheable only if specified by Cache-Control or Expires. The new temporary URI should be returned in the Location field of the response. Unless it is a HEAD request, the response entity should include a hyperlink to the new URI and a brief explanation. If it is not a GET or HEAD request, browsers are prohibited from automatically redirecting unless confirmed by the user, as the request conditions may have changed. Note: Although RFC 1945 and RFC 2068 specifications do not allow clients to change the request method during redirection, many existing browsers treat 302 responses as 303 responses and use the GET method to access the URI specified in Location, regardless of the original request method. Status codes 303 and 307 were added to clarify the server's expectations for client behavior. |
| 303 |
The response to the request can be found under a different URI and should be accessed using the GET method. This method exists primarily to allow POST requests activated by scripts to redirect to a new resource. The new URI is not a substitute reference for the original resource. Additionally, 303 responses are not cacheable. However, the second request (redirection) may be cached. The new URI should be returned in the Location field of the response. Unless it is a HEAD request, the response entity should include a hyperlink to the new URI and a brief explanation. Note: Many HTTP/1.1-compliant browsers cannot correctly understand 303 status. If interaction with these browsers is a concern, the 302 status code may be suitable, as most browsers handle 302 responses in the way required by the specification for handling 303 responses. |
| 304 |
If the client has sent a conditional GET request that was allowed, and the content of the document (since the last access or based on the conditions of the request) has not changed, the server should return this status code. A 304 response is prohibited from containing a message body and thus always ends with the first empty line after the headers. The response must include the following headers: Date, unless the server has no clock. If a clockless server complies with these rules, proxy servers and clients can add the Date field to the received response headers (as specified in RFC 2068), and the caching mechanism will work correctly. ETag and/or Content-Location, if the same request would otherwise return a 200 response. Expires, Cache-Control, and/or Vary, if their values may differ from those in other responses for the same variant. If the request used strong cache validation, the response should not include other entity-headers; otherwise (e.g., a conditional GET request using weak cache validation), the response must not include other entity-headers; this avoids inconsistency between the cached entity-body and the updated entity-headers. If a 304 response indicates that a certain entity is not cached, the caching system must ignore this response and resend the request without restrictions. If a 304 response is received to update a cached entry, the caching system must update the entire entry to reflect any updated field values in the response. |
| 305 |
The requested resource must be accessed through the specified proxy. The Location field will give the URI of the specified proxy, and the recipient needs to send a separate request through this proxy to access the corresponding resource. Only the origin server can establish a 305 response. Note: RFC 2068 does not explicitly state that a 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 temporarily responding from a different URI. Since this redirection is temporary, clients should continue to send future requests to the original address. This response is cacheable only if specified by Cache-Control or Expires. The new temporary URI should be returned in the Location field of the response. Unless it is a HEAD request, the response entity should include a hyperlink to the new URI and a brief explanation. Because some browsers cannot recognize 307 responses, it is necessary to add the necessary information so that users can understand and make a request to the new URI. If it is not a GET or HEAD request, browsers are prohibited from automatically redirecting unless confirmed by the user, as the request conditions may have changed. |
| 400 |
1. Bad Request - The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing). Unless the request method was HEAD, the response MUST include an entity containing a description of the error situation, and whether it is a temporary or permanent condition. 2. Invalid request parameters. |
| 401 |
Unauthorized - Similar to 403 Forbidden, but specifically for access control and authentication. The server understands the request but refuses to authorize it. This response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field. If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the previous response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented with the entity information contained in the response body, because it may include relevant diagnostic information. |
| 402 |
Payment Required - Reserved for future use as the means by which this status code is assigned has been deprecated. |
| 403 |
Forbidden - The server understood the request but refuses to authorize it. Unlike 401, authenticating will make no difference. This request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has been forbidden, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead. A 403 response is commonly used when the server wants to refuse service to the client. |
| 404 |
Not Found - The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code is used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable. |
| 405 |
Method Not Allowed - The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header field containing a list of valid methods for the requested resource. PUT and DELETE methods are typically disabled on web servers by default due to their potential to modify resources on the server. |
| 406 |
Not Acceptable - The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request. Unless it is a HEAD request, the response MUST include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending on the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection. |
| 407 |
Proxy Authentication Required - The client must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field containing a challenge applicable to the proxy for the target resource. The client MAY repeat the request with a suitable Proxy-Authorization header field. See RFC 2617. |
| 408 |
Request Timeout - 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 later time. |
| 409 |
Conflict - 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 it is expected that the user might be able to resolve the conflict and resubmit the request. The response body should include enough information for the user or user agent to recognize the source of the conflict. Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format that would be meaningful to the user. |
| 410 |
Gone - Indicates that the resource requested is no longer available and will not be available again. This should be used when a resource has been intentionally removed and the resource should be purged from the origin server and the user agent SHOULD NOT retry the request. If the server does not know or has no facility to determine whether or not the condition is permanent, the status code 404 (Not Found) should be used instead. This response is cacheable unless indicated otherwise. |
| 411 |
Length Required - The server refuses to accept the request without a defined Content-Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message body. |
| 412 |
Precondition Failed: The server does not meet one or more of the preconditions set in the request's header fields for the requested resource. This status code allows the client to set preconditions in the request's metadata (header field data) to avoid the request method being applied to resources other than those intended. |
| 413 |
Payload Too Large: The server is refusing to process a request because the request entity is larger than the server is willing or able to process. In this case, 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 field to indicate when the client may retry the request. |
| 414 |
URI Too Long: The server is refusing to service the request because the request-URI is longer than the server is capable of interpreting. This rarely occurs and can include scenarios such as: a form submission intended to use the POST method being mistakenly used as GET, resulting in an excessively long query string; redirect URI "black holes", where each redirect appends the old URI to the new one, causing the URI to become excessively long after several redirects; or attempts by clients to exploit security vulnerabilities in certain servers by manipulating the URI. Servers without such vulnerabilities should return a 414 status code. |
| 415 |
Unsupported Media Type: The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method. |
| 416 |
Requested Range Not Satisfiable: The server cannot fulfill the request because the Range header field specified a range for which the requested resource's size is less than the specified range's start or end value, or because the start value is greater than the end value. In the case of a byte-range request, this means that the client has asked for a portion of the file starting at a position beyond the actual size of the file. The server should include a Content-Range header field indicating the current size of the requested resource in its response to a 416 status code. This response must not use the multipart/byteranges Content-Type. |
| 417 |
Expectation Failed: The server cannot meet the Expectation set in the Expect request-header field. |
| 421 |
Misdirected Request: The request was directed to a server that is not able to produce a response (for example, because a connection reuse was attempted when the previous response indicated that it should not be reused). This status code is also used when the server is a proxy and it has a clear evidence that the requested URI is malformed and cannot be processed by the next hop. |
| 422 |
Unprocessable Entity: The request was well-formed but was unable to be followed due to semantic errors. (RFC 4918 WebDAV) 423 Locked: The resource that is being accessed is locked. (RFC 4918 WebDAV) |
| 424 |
Failed Dependency: The request failed due to failure of a previous request (e.g., a PROPPATCH). (RFC 4918 WebDAV) |
| 425 |
Unordered Collection: Defined in the WebDav Advanced Collections draft but not present in "WebDAV Ordered Collections Protocol" (RFC 3658). |
| 426 |
Upgrade Required: The client should switch to a different protocol, such as TLS/1.0, as requested by the server. (RFC 2817) |
| 449 |
Retry With: A Microsoft extension that indicates 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 issue arises due to an error in 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 its request for any resource. |
| 502 |
As a gateway or proxy, the server received an invalid response from an upstream server while attempting to process the request. |
| 503 |
The server is currently unable to handle the request due to temporary maintenance or overloading. This condition is temporary and will be resolved after some time. If the delay time can be estimated, the response may include a Retry-After header indicating this delay. 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 imply that it must be used when the server is overloaded. Some servers simply wish to deny client connections. |
| 504 |
As a gateway or proxy, the server did not receive a timely response from an upstream server (identified by the URI, such as HTTP, FTP, LDAP) or an auxiliary server (such as DNS) while attempting to process the request. Note: Some proxy servers return 400 or 500 errors when DNS queries time 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 will not 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 |
As per the Transparent Content Negotiation Protocol (RFC 2295) extension, this represents an internal configuration error on the server: the requested negotiation variant resource is configured to use itself in transparent content negotiation, thus making it an unsuitable focus in a negotiation process. |
| 507 |
The server is unable to store the content necessary to complete the request. This condition is considered temporary. (WebDAV, RFC 4918) |
| 509 |
Bandwidth Limit Exceeded. This is not an official status code but is still widely used. |
| 510 |
The policy required to obtain the resource has not been satisfied. (RFC 2774) |