HTTP Status Code Reference Table
When a browser accesses a webpage, it sends a request to the server hosting that webpage. Before the browser receives and displays the webpage, the server returns a header containing the HTTP status code to respond to the browser’s request.
The English term for HTTP status code is HTTP Status Code. Below are some common HTTP status codes:
- • 200 – Request succeeded
- • 301 – Resource (webpage, etc.) has been permanently moved to another URL
- • 404 – The requested resource (webpage, etc.) does not exist
- • 500 – Internal server error
Classification of HTTP Status Codes
HTTP status codes consist of three decimal digits, with the first digit defining the type of status code, while the last two digits do not have a classification function. HTTP status codes are divided into five categories:
| Category | Description |
|---|---|
| 1** | Informational, the server has received the request and the requester needs to continue with the operation |
| 2** | Success, the operation has been successfully received and processed |
| 3** | Redirection, further action is needed to complete the request |
| 4** | Client error, the request contains syntax errors or cannot be completed |
| 5** | Server error, an error occurred while processing the request |
HTTP Status Code Table (Version 1) This table includes the English names of status codes
| Status Code | English Name | Description |
|---|---|---|
| 1xx Status Codes | ||
| 100 | Continue | Continue. The client should continue its request |
| 101 | Switching Protocols | The server is switching protocols according to the client’s request. Can only switch to a higher-level protocol, such as switching to a new version of HTTP |
| 102 | Extended status code by WebDAV (RFC 2518), indicating that processing will continue. | |
| 2xx Status Codes | ||
| 200 | OK | Request succeeded. Generally used for GET and POST requests |
| 201 | Created | Created. The request was successful and a new resource was created |
| 202 | Accepted | Accepted. The request has been accepted but not yet processed |
| 203 | Non-Authoritative Information | Non-authoritative information. The request succeeded, but the returned meta-information is not from the original server, but a copy |
| 204 | No Content | No content. The server successfully processed the request but did not return any content. This ensures the browser continues to display the current document without updating the webpage |
| 205 | Reset Content | Reset content. The server successfully processed the request, and the user agent (e.g., browser) should reset the document view. This return code can clear the browser’s form fields |
| 206 | Partial Content | Partial content. The server successfully processed part of the GET request |
| 207 | Extended status code by WebDAV (RFC 2518), indicating that the subsequent message body will be an XML message and may contain a series of independent response codes depending on the number of previous sub-requests. | |
| 3xx Status Codes | ||
| 300 | Multiple Choices | The requested resource has multiple options for feedback, each with its specific address and browser-driven business information. Users or browsers can choose a preferred address for redirection. Unless this is a HEAD request, the response should include an entity listing the resource characteristics and addresses for users or browsers to select the most suitable redirection address. The format of this entity is determined by the format defined by Content-Type. Browsers may automatically make the most suitable choice based on the response format and their capabilities. Of course, RFC 2616 does not specify how such automatic selection should be made. If the server already has a preferred feedback choice, the URI of this feedback should be indicated in the Location; the browser may use this Location value as the automatic redirection address. Additionally, unless otherwise specified, this response is also cacheable. |
| 301 | Moved Permanently | The requested resource has been permanently moved to a new location, and any 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 returned by the server. Unless otherwise specified, this response is also cacheable. The new permanent URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. If this is not a GET or HEAD request, the browser is prohibited from automatically redirecting unless user confirmation is obtained, as the conditions of the request may change. Note: For some browsers using the HTTP/1.0 protocol, when they send a POST request and receive a 301 response, the subsequent redirection request will become a GET request. |
| 302 | Found | The requested resource is now temporarily responding from 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. The new temporary URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. If this is not a GET or HEAD request, the browser is prohibited from automatically redirecting unless user confirmation is obtained, as the conditions of the request may change. Note: Although RFC 1945 and RFC 2068 do not allow clients to change the request method during redirection, many existing browsers treat a 302 response as a 303 response and access the URI specified in Location using the GET method, ignoring the original request method. Status codes 303 and 307 were added to clarify what response the server expects from the client. |
| 303 | See Other | 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 primarily to allow script-activated POST request outputs to redirect to a new resource. This new URI is not an alternative reference to the original resource. Meanwhile, 303 responses are prohibited from being cached. Of course, the second request (redirection) may be cached. The new URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. Note: Many browsers prior to HTTP/1.1 do not correctly understand the 303 status. If interaction with these browsers is a concern, the 302 status code should suffice, as most browsers handle 302 responses in the manner that the specification requires clients to handle 303 responses. |
| 304 | Not Modified | Not modified. The requested resource has not been modified, and the server does not return any resource when returning this status code. Clients typically cache accessed resources and indicate a header that the client wishes to return only resources modified after a specified date |
| 305 | Use Proxy | The requested resource must be accessed through the specified proxy. The Location field will provide the URI information of the specified proxy, and the recipient needs to resend a separate request through this proxy to access the corresponding resource. Only the original server can establish a 305 response. Note: RFC 2068 does not explicitly state that a 305 response is for redirecting a single request and can only be established by the original server. Ignoring these restrictions may lead to serious security consequences. |
| 306 | Unused | This HTTP status code has been deprecated |
| 307 | Temporary Redirect | The requested resource is now temporarily responding from 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. The new temporary URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. Since some browsers cannot recognize 307 responses, the necessary information should be added to help users understand and make requests to the new URI. If this is not a GET or HEAD request, the browser is prohibited from automatically redirecting unless user confirmation is obtained, as the conditions of the request may change. |
| 4xx Status Codes | ||
| 400 | Bad Request | There is a syntax error in the client request, and the server cannot understand it |
| 401 | Unauthorized | The request requires user authentication |
| 402 | Payment Required | Reserved for future use |
| 403 | Forbidden | The server understands the client’s request but refuses to execute it |
| 404 | Not Found | The server cannot find the resource (webpage) based on the client’s request. This code allows web designers to set up a personalized page stating “The resource you requested cannot be found” |
| 405 | Method Not Allowed | The method specified in the client request is not allowed for the requested resource |
| 406 | Not Acceptable | The server cannot fulfill the request based on the content characteristics specified in the client request |
| 407 | Proxy Authentication Required | The request requires proxy authentication, similar to 401, but the requester should use the proxy for authorization |
| 408 | Request Time-out | The server waited too long for the client to send the request, timing out |
| 409 | Conflict | The server may return this code when completing the client’s PUT request, indicating a conflict occurred while processing the request |
| 410 | Gone | The requested resource is no longer available. 410 differs from 404; if a resource previously existed and has now been permanently deleted, the 410 code can be used. Web designers can specify the new location of the resource using the 301 code |
| 411 | Length Required | The server cannot process the request information sent by the client without a Content-Length |
| 412 | Precondition Failed | The preconditions in the client request information are incorrect |
| 413 | Request Entity Too Large | The server cannot process the request because the entity is too large. To prevent continuous requests from the client, the server may close the connection. If the server is temporarily unable to process the request, it will include a Retry-After response message |
| 414 | Request-URI Too Large | The requested URI is too long (the URI is usually the URL), and the server cannot process it |
| 415 | Unsupported Media Type | The server cannot process the media format attached to the request |
| 416 | Requested range not satisfiable | The range requested by the client is invalid |
| 417 | Expectation Failed | The server cannot meet the expectations specified in the Expect request header |
| 421 | There are more connections from the current client’s IP address to the server than the server allows. Typically, this IP address refers to the client address seen from the server (e.g., the user’s gateway or proxy server address). In this case, the connection count may involve more than one end user. | |
| 422 | There are more connections from the current client’s IP address to the server than the server allows. Typically, this IP address refers to the client address seen from the server (e.g., the user’s gateway or proxy server address). In this case, the connection count may involve more than one end user. | |
| 422 | The request format is correct, but it 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 from a previous request, such as PROPPATCH. (RFC 4918 WebDAV) | |
| 425 | Defined in the WebDav Advanced Collections draft but not appearing in the WebDAV Ordered Collection Protocol (RFC 3658). | |
| 426 | The client should switch to TLS/1.0. (RFC 2817) | |
| 449 | Extended by Microsoft, indicating that the request should be retried after performing the appropriate action. | |
| 5xx Status Codes | ||
| 500 | Internal Server Error | The server encountered an unexpected condition that prevented it from fulfilling the request |
| 501 | Not Implemented | The server does not support the functionality required to fulfill the request |
| 502 | Bad Gateway | The server acting as a gateway or proxy received an invalid response from the upstream server |
| 503 | Service Unavailable | The server is temporarily unable to handle the request due to overload or maintenance. The length of the delay may be included in the server’s Retry-After header |
| 504 | Gateway Time-out | The server acting as a gateway or proxy did not receive a timely response from the upstream server |
| 505 | HTTP Version not supported | The server does not support the HTTP protocol version that was used in the request |
| 506 | Extended by the Transparent Content Negotiation Protocol (RFC 2295), indicating that the server has an internal configuration error: the requested negotiation variable resource is configured to use itself in transparent content negotiation, making it an unsuitable focus in a negotiation process. | |
| 507 | The server cannot store the content necessary to fulfill 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 still widely used. | |
| 510 | The policy required to access the resource has not been met. (RFC 2774) |
HTTP Status Code List (Version 2) This table provides more detailed descriptions
| Status Code | Meaning | |
|---|---|---|
| 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 yet been rejected. The client should continue sending the remaining part of the request, or if the request is complete, ignore this response. The server must send a final response to the client after the request is completed. | |
| 101 | The server has understood the client’s request and will notify the client to adopt a different protocol to complete this request via the Upgrade message header. After sending this response’s final empty line, the server will switch to the protocols defined in the Upgrade message header. Only when switching to a new protocol is more beneficial should such measures be taken. For example, switching to a new version of HTTP is more advantageous than the old version, or switching to a real-time and synchronous protocol to transmit resources utilizing such features. | |
| 102 | Extended status code by WebDAV (RFC 2518), indicating that processing will continue. | |
| 200 | The request has succeeded, and the desired response headers or data body will be returned with this response. | |
| 201 | The request has been implemented, and a new resource has been created based on the request, and its URI has been returned with the Location header. If the required resource cannot be created in a timely manner, ‘202 Accepted’ should be returned. | |
| 202 | The server has accepted the request but has not yet processed it. As it may be rejected, the request may or may not be executed eventually. In asynchronous operations, there is no more convenient way than sending this status code. The purpose of returning a 202 status code is to allow the server to accept requests for other processes (e.g., a batch operation that only executes once a day) without requiring the client to maintain a connection with the server until the batch operation is complete. The response returning the 202 status code should include some indication of the current status of the processing in the returned entity, as well as pointers to processing status monitors or status predictions, so that users can estimate whether the operation has been completed. | |
| 203 | The server has successfully processed the request, but the returned entity header information is not a valid definitive set from the original server but a copy from a local or third party. The current information may be a subset or superset of the original version. For example, the metadata containing the resource may lead the original server to know the metadata is super. Using this status code is not mandatory and is only appropriate when the response would return 200 OK if this status code were not used. | |
| 204 | The server has 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 to the requested variables. If the client is a browser, the user’s browser should retain the page that sent the request without causing any changes in the document view, even though according to the specification, 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 containing any message body, it always ends with the first empty line after the message headers. | |
| 205 | The server has successfully processed the request and has not returned any content. However, unlike the 204 response, the response returning this status code requires the requester to reset the document view. This response is mainly used to reset forms immediately after accepting user input, allowing users to easily start another input. Like the 204 response, this response is also prohibited from containing any message body and ends with the first empty line after the message headers. | |
| 206 | The server has successfully processed part of the GET request. HTTP download tools like FlashGet or Thunder use this type of response to implement breakpoint continuation or to break a large document into multiple segments for simultaneous downloading. The request must include a Range header to indicate the content range the client wishes to receive, and 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 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 content range returned. Date, ETag and/or Content-Location, if the same request should have returned a 200 response. Expires, Cache-Control, and/or Vary, if their values may differ from those corresponding to other responses with the same variables. If this response request used If-Range strong cache validation, this response should not include other entity headers; if this response request used If-Range weak cache validation, this response is prohibited from including other entity headers; this avoids inconsistencies between cached entity content and updated entity header information. Otherwise, this response should include all entity header fields that should have been returned in a 200 response. If the ETag or Last-Modified headers cannot match precisely, the client cache should be prohibited from combining the content returned in the 206 response with any previously cached content. Any cache that does not support Range and Content-Range headers is prohibited from caching the content returned in the 206 response. | |
| 207 | Extended status code by WebDAV (RFC 2518), indicating that the subsequent message body will be an XML message and may contain a series of independent response codes depending on the number of previous sub-requests. | |
| 300 | Multiple Choices | The requested resource has multiple options for feedback, each with its specific address and browser-driven business information. Users or browsers can choose a preferred address for redirection. Unless this is a HEAD request, the response should include an entity listing the resource characteristics and addresses for users or browsers to select the most suitable redirection address. The format of this entity is determined by the format defined by Content-Type. Browsers may automatically make the most suitable choice based on the response format and their capabilities. Of course, RFC 2616 does not specify how such automatic selection should be made. If the server already has a preferred feedback choice, the URI of this feedback should be indicated in the Location; the browser may use this Location value as the automatic redirection address. Additionally, unless otherwise specified, this response is also cacheable. |
| 301 | Moved Permanently | The requested resource has been permanently moved to a new location, and any 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 returned by the server. Unless otherwise specified, this response is also cacheable. The new permanent URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. If this is not a GET or HEAD request, the browser is prohibited from automatically redirecting unless user confirmation is obtained, as the conditions of the request may change. Note: For some browsers using the HTTP/1.0 protocol, when they send a POST request and receive a 301 response, the subsequent redirection request will become a GET request. |
| 302 | Found | The requested resource is now temporarily responding from 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. The new temporary URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. If this is not a GET or HEAD request, the browser is prohibited from automatically redirecting unless user confirmation is obtained, as the conditions of the request may change. Note: Although RFC 1945 and RFC 2068 do not allow clients to change the request method during redirection, many existing browsers treat a 302 response as a 303 response and access the URI specified in Location using the GET method, ignoring the original request method. Status codes 303 and 307 were added to clarify what response the server expects from the client. |
| 303 | See Other | 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 primarily to allow script-activated POST request outputs to redirect to a new resource. This new URI is not an alternative reference to the original resource. Meanwhile, 303 responses are prohibited from being cached. Of course, the second request (redirection) may be cached. The new URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. Note: Many browsers prior to HTTP/1.1 do not correctly understand the 303 status. If interaction with these browsers is a concern, the 302 status code should suffice, as most browsers handle 302 responses in the manner that the specification requires clients to handle 303 responses. |
| 304 | Not Modified | If the client sent a conditional GET request and that request has been allowed, and the content of the document (since the last visit or based on the request conditions) has not changed, the server should return this status code. The 304 response prohibits the inclusion of a message body, thus always ending with the first empty line after the message headers. This response must include the following header information: Date, unless this server has no clock. If a server without a clock also follows these rules, then 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 normally. ETag and/or Content-Location, if the same request should have returned a 200 response. Expires, Cache-Control, and/or Vary, if their values may differ from those corresponding to other responses with the same variables. If this response request used strong cache validation, this response should not include other entity headers; otherwise (for example, if a conditional GET request used weak cache validation), this response prohibits including other entity headers; this avoids inconsistencies between cached entity content and updated entity header information. If a 304 response indicates that a certain entity is not cached, the caching system must ignore this response and resend a request without conditional limits. If a 304 response is received that requires updating a cached entry, the caching system must update the entire entry to reflect all the values of the fields updated in the response. |
| 305 | Use Proxy | The requested resource must be accessed through the specified proxy. The Location field will provide the URI information of the specified proxy, and the recipient needs to resend a separate request through this proxy to access the corresponding resource. Only the original server can establish a 305 response. Note: RFC 2068 does not explicitly state that a 305 response is for redirecting a single request and can only be established by the original server. Ignoring these restrictions may lead to serious security consequences. |
| 306 | Unused | This status code is no longer used in the latest specifications. |
| 307 | Temporary Redirect | The requested resource is now temporarily responding from 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. The new temporary URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. Since some browsers cannot recognize 307 responses, the necessary information should be added to help users understand and make requests to the new URI. If this is not a GET or HEAD request, the browser is prohibited from automatically redirecting unless user confirmation is obtained, as the conditions of the request may change. |
| 400 | 1. Semantic error, the current request cannot be understood by the server. Unless modified, the client should not repeat this request. 2. Request parameters are incorrect. | |
| 401 | The current request requires user authentication. This response must include a WWW-Authenticate information header applicable to the requested resource to inquire about user information. The client can repeat the request containing the appropriate Authorization header. If the current request already contains the Authorization certificate, then the 401 response indicates that the server has rejected those certificates. If the 401 response contains the same authentication inquiry as the previous response, and the browser has attempted verification at least once, the browser should display the entity information contained in the response, as this entity information may contain relevant diagnostic information. See RFC 2617. | |
| 402 | This status code is reserved for possible future requirements. | |
| 403 | The server has understood the request but refuses to execute it. Unlike the 401 response, authentication does not help, and this request should not be repeated. If this is not a HEAD request, and the server wishes to clarify why the request cannot be executed, it should describe the reason for the refusal in the entity. Of course, the server can also return a 404 response if it does not wish to provide any information to the client. | |
| 404 | Request failed, the resource the request hoped to obtain was not found on the server. No information can tell the user whether this situation is temporary or permanent. If the server knows the situation, it should use the 410 status code to inform that the old resource is permanently unavailable due to some internal configuration mechanism issue, and there is no address to redirect to. The 404 status code is widely used when the server does not want to reveal why the request was rejected or when no other 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 to indicate the list of request methods that the current resource can accept. Since PUT and DELETE methods will perform write operations on resources on the server, most web servers do not support or allow these request methods by default, and will return a 405 error for such requests. | |
| 406 | The content characteristics of the requested resource cannot satisfy the conditions in the request headers, thus preventing the generation of a response entity. Unless this is a HEAD request, this response should return an entity containing a list of characteristics and addresses that allow the user or browser to select the most suitable entity characteristics. The entity format is determined by the media type defined in the Content-Type header. Browsers can make the best choice based on 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 on the proxy server. The proxy server must return a Proxy-Authenticate to inquire about authentication. The client can return a Proxy-Authorization information header for verification. See RFC 2617. | |
| 408 | Request timeout. The client did not complete sending a request within the time the server was prepared to wait. The client can resubmit this request at any time without making any changes. | |
| 409 | Due to a conflict with the current state of the requested resource, the request cannot be completed. This code is only allowed to be used in situations where the user is considered able to resolve the conflict and will resubmit a new request. This response should contain enough information for the user to discover the source of the conflict. Conflicts usually occur in the processing of PUT requests. For example, in a version-checking environment, if the version information attached to a modification request for a specific resource conflicts with a previous (third-party) request, the server should return a 409 error, informing the user that the request cannot be completed. At this time, the response entity may contain a comparison of the differences between the two conflicting versions, allowing the user to resubmit a merged new version. | |
| 410 | The requested resource is no longer available on the server, and there is no known forwarding address. This situation should be considered permanent. If possible, clients with link editing capabilities should delete all 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 otherwise specified, this response is cacheable. The purpose of the 410 response is mainly to help website administrators maintain the site, notifying users that the resource is no longer available, and the server owner wishes all remote connections pointing to this resource to be deleted. Such events are common in limited-time, value-added services. Similarly, the 410 response is also used to inform clients that a resource that originally belonged to a person is no longer available on the current server site. Of course, whether to mark all permanently unavailable resources as ‘410 Gone’ and how long to maintain this mark 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 the 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 header fields. This status code allows the client to set preconditions in the request metadata (request header field data) when obtaining resources to avoid applying the request method to resources outside of what it wishes. | |
| 413 | The server refuses to process the current request because the size of the entity data submitted in the request exceeds the range that the server is willing or able to process. In this case, 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 it can retry. | |
| 414 | The length of the requested URI exceeds the length that the server can interpret, thus the server refuses to provide service for that request. This is rare and usually occurs in situations such as: a form submission that should have used the POST method turning into a GET method, resulting in an excessively long query string; a redirect URI “black hole,” where each redirect includes the old URI as part of the new URI, leading to an excessively long URI after several redirects; or the client attempting to exploit a security vulnerability present in some servers. Servers that do not have such vulnerabilities should return a 414 status code. | |
| 415 | The entity submitted in the request is not in a format supported by the server for the current request method and requested resource, thus the request is rejected. | |
| 416 | If the request includes a Range request header, and any data range specified in the Range does not overlap with the available range of the current resource, and the request does not define an If-Range request header, then the server should return a 416 status code. If the Range uses byte ranges, this situation means that the first byte position of all data ranges specified in the request exceeds the length of the current resource. The server should also include a Content-Range entity header indicating the length of the current resource when returning a 416 status code. This response is also prohibited from using multipart/byteranges as its Content-Type. | |
| 417 | The expected content specified in the Expect request header cannot be satisfied by the server, or this server is a proxy server that has clear evidence that the content of Expect cannot be satisfied at the next node in the current route. | |
| 421 | There are more connections from the current client’s IP address to the server than the server allows. Typically, this IP address refers to the client address seen from the server (e.g., the user’s gateway or proxy server address). In this case, the connection count may involve more than one end user. | |
| 422 | There are more connections from the current client’s IP address to the server than the server allows. Typically, this IP address refers to the client address seen from the server (e.g., the user’s gateway or proxy server address). In this case, the connection count may involve more than one end user. | |
| 422 | The request format is correct, but it 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 from a previous request, such as PROPPATCH. (RFC 4918 WebDAV) | |
| 425 | Defined in the WebDav Advanced Collections draft but not appearing in the WebDAV Ordered Collection Protocol (RFC 3658). | |
| 426 | The client should switch to TLS/1.0. (RFC 2817) | |
| 449 | Extended by Microsoft, indicating that the request should be retried after performing the appropriate action. | |
| 500 | The server encountered an unexpected condition that prevented it from fulfilling the request. Generally, this problem occurs when there is an error in the server’s program code. | |
| 501 | The server does not support a certain functionality required by the current request. When the server cannot recognize the request method and cannot support its request for any resource. | |
| 502 | The server acting as a gateway or proxy received an invalid response while trying to execute the request from the upstream server. | |
| 503 | The server is temporarily unable to handle the request due to maintenance or overload. This situation is temporary and will recover after a period of time. If the delay time can be anticipated, the response may include a Retry-After header indicating this delay time. If this Retry-After information is not provided, the client should handle it as a 500 response. Note: The existence of the 503 status code does not mean that the server must use it when overloaded. Some servers simply wish to refuse the client’s connection. | |
| 504 | The server acting as a gateway or proxy did not receive a timely response from the upstream server (the server identified by the URI, such as HTTP, FTP, LDAP) or auxiliary server (such as DNS) while trying to execute the request. Note: Some proxy servers may return 400 or 500 errors on DNS query timeouts. | |
| 505 | The server does not support or refuses to support the HTTP version used in the request. This implies that the server cannot or does not wish 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 an internal configuration error: the requested negotiation variable resource is configured to use itself in transparent content negotiation, making it an unsuitable focus in a negotiation process. | |
| 507 | The server cannot store the content necessary to fulfill 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 still widely used. | |
| 510 | The policy required to access the resource has not been met. (RFC 2774) |