| HTTP status code |
Status code meaning |
| 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 yet been rejected. The client should continue sending the remaining part of the request, or if the request has been completed, 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 inform the client to use a different protocol to complete the request through the Upgrade message header. After sending the last blank line of this response, the server will switch to the protocols defined in the Upgrade message header. Such measures should only be taken when switching to a new protocol is more beneficial. For example, switching to a new HTTP version is more advantageous than the old version, or switching to a real-time and synchronous protocol to transmit resources that utilize such features. |
| 102 |
Status code extended by WebDAV (RFC 2518), indicating that processing will continue. |
| 200 |
The request has succeeded. The response headers or data body expected by the request will be returned with this response. |
| 201 |
The request has been fulfilled, and a new resource has been created according to the request, with its URI returned in the Location header. If the required resource cannot be created in time, '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 eventually be executed. In the case of asynchronous operations, there is no more convenient way than sending this status code. The purpose of returning a 202 status code response is to allow the server to accept requests for other processes (such as a batch operation that runs only once a day) without requiring the client to keep the connection until the batch operation is fully completed. The response that accepts the request and returns a 202 status code should include information indicating the current processing status in the returned entity, as well as a pointer to the processing status monitor or status prediction, so that users can estimate whether the operation has been completed. |
| 203 |
The server has successfully processed the request, but the returned entity header meta-information is not a valid set on the origin server, but a copy from local or a third party. The current information may be a subset or superset of the original version. For example, metadata containing the resource may cause the origin server to know the super of the meta-information. Using this status code is not required, and is only appropriate if the response would otherwise return 200 OK without using this status code. |
| 204 |
The server has successfully processed the request, but does not need to return any entity content, and wants to return updated meta-information. The response may return new or updated meta-information in the form of entity headers. If these headers exist, they should correspond to the requested variables. If the client is a browser, the user browser should retain the page that sent the request without any changes in the document view, even if the specification requires that new or updated meta-information should be applied to the document in the user's active view. Because 204 responses are prohibited from containing any message body, they always end with the first blank line after the headers. |
| 205 |
The server has successfully processed the request and returned no content. However, unlike a 204 response, a response returning this status code requires the requester to reset the document view. This response is mainly used to immediately reset the form after accepting user input, so that users can easily start another input. Like the 204 response, this response is also prohibited from containing any message body and ends with the first blank line after the headers. |
| 206 |
The server has successfully processed a partial GET request. HTTP download tools such as FlashGet or Thunder use this type of response to implement resumable downloads or break a large document into multiple download segments for simultaneous downloading. The request must include the Range header to indicate the content range the client wants, and may include If-Range as a request condition. The response must include the following headers: Content-Range to indicate the range of content returned in this response; if the Content-Type is multipart/byteranges for multi-part downloads, each multipart segment must include a Content-Range header 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 have returned a 200 response. Expires, Cache-Control, and/or Vary, if their values may differ from those in other responses to the same variant. If this response request used If-Range strong cache validation, then this response should not include other entity headers; if this response request used If-Range weak cache validation, then 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 would have been returned in a 200 response. If the ETag or Last-Modified headers do not match exactly, the client cache must not combine the content returned by the 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 the 206 response. |
| 207 |
Status code extended by WebDAV (RFC 2518), indicating that the following 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 |
The requested resource has a series of alternative responses available, each with its own specific address 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 containing a list of resource characteristics and addresses, so that the user or browser can choose the most appropriate redirection address. The format of this entity is determined by the Content-Type. The browser may automatically make the most appropriate choice based on the response format and its own capabilities. Of course, the RFC 2616 specification does not prescribe how such automatic selection should be performed. If the server itself has a preferred alternative, it should indicate the URI of this alternative in the Location header; the browser may use this Location value as the automatic redirection address. Additionally, unless otherwise specified, this response is also 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 several URIs returned in this response. If possible, clients with link editing capabilities should automatically change the request address to the one returned from the server. Unless otherwise specified, this response is also cacheable. The new permanent URI should be returned in the Location header of the response. Unless it 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, browsers are prohibited from automatically redirecting without user confirmation, because the request conditions may change. Note: For some browsers using HTTP/1.0, when they send a POST request and receive a 301 response, the subsequent redirected request will become a GET method. |
| 302 |
The requested resource currently responds to the request from a different URI. Since such redirection is temporary, the client should continue to send future requests to the original address. This response is cacheable only if specified in Cache-Control or Expires. The new temporary URI should be returned in the Location header of the response. Unless it 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, browsers are prohibited from automatically redirecting without user confirmation, because the request conditions may change. 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 what response the server expects from the client.
|
| 303 |
The response to the current request can be found at another URI, and the client should use the GET method to access that resource. The existence of this method is mainly to allow POST request outputs activated by scripts to be redirected to a new resource. This new URI is not a substitute reference for 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 header of the response. Unless it is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. Note: Many browsers before HTTP/1.1 do not correctly understand the 303 status. If interaction with these browsers needs to be considered, the 302 status code should suffice, because most browsers handle 302 responses in exactly the way the specification requires clients to handle 303 responses. |
| 304 |
If the client sends a conditional GET request that has been allowed, and the document content (since the last access or according to the request conditions) has not changed, the server should return this status code. 304 responses are prohibited from containing a message body, so they always end with the first blank line after the headers. This response must include the following headers: Date, unless the server does not have a clock. If a server without a clock also follows these rules, then proxies and clients can add the Date field to the received response headers themselves (as specified in RFC 2068), and the caching mechanism will work correctly. ETag and/or Content-Location, if the same request would have returned a 200 response. Expires, Cache-Control, and/or Vary, if their values may differ from those in other responses to the same variant. If this response request used strong cache validation, then this response should not include other entity headers; otherwise (for example, a conditional GET request using weak cache validation), this response is prohibited from 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 the request without restrictions. If a 304 response requiring an update to a cached entry is received, the caching system must update the entire entry to reflect all updated field values in the response.
|
| 305 |
The requested resource must be accessed through the specified proxy. The Location header will provide the URI information of the specified proxy. The recipient needs to resend a separate request to access the corresponding resource through this proxy. Only the origin server can generate a 305 response. Note: RFC 2068 does not explicitly state that the 305 response is for redirecting a single request and can only be generated by the origin server. Ignoring these restrictions may lead to serious security consequences. |
| 306 |
In the latest specification, the 306 status code is no longer used. |
| 307 |
The requested resource currently responds to the request from a different URI. Since such redirection is temporary, the client should continue to send future requests to the original address. This response is cacheable only if specified in Cache-Control or Expires. The new temporary URI should be returned in the Location header of the response. Unless it is a HEAD request, the response entity should contain a hyperlink to the new URI and a brief description. Because some browsers cannot recognize 307 responses, the above necessary information needs to be added so that users can understand and send access requests to the new URI. If this is not a GET or HEAD request, browsers are prohibited from automatically redirecting without user confirmation, because the request conditions may change. |
| 400 |
1. The request could not be understood by the server due to incorrect syntax. The client should not repeat the request without modifications. 2. The request parameters are incorrect. |
| 401 |
The current request requires user authentication. The response must include a WWW-Authenticate header applicable to the requested resource to query user information. The client can resubmit a request with the appropriate Authorization header. If the current request already contains Authorization credentials, a 401 response indicates that server authentication has rejected those credentials. If the 401 response contains the same authentication challenge as the previous response, and the browser has already attempted authentication at least once, the browser should display the entity information contained in the response to the user, as this information may contain relevant diagnostic details. See RFC 2617. 2617。 |
| 402 |
This status code is reserved for possible future requirements. |
| 403 |
The server understood the request but refuses to fulfill it. Unlike a 401 response, authentication will not help, and the request should not be repeated. If it is not a HEAD request and the server wishes to explain why the request cannot be fulfilled, it should describe the reason in the entity. Alternatively, the server may return a 404 response if it does not want to provide any information to the client. |
| 404 |
The request failed; the requested resource was not found on the server. There is no information to indicate whether this condition 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 issues, 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 rejected or when no other appropriate response is available. |
| 405 |
The request method specified in the request line cannot be used for the corresponding resource. The response must include an Allow header listing the request methods that the current resource can accept. Given that PUT and DELETE methods perform write operations on server resources, most web servers do not support or do not allow these request methods in the default configuration, and will return a 405 error for such requests. |
| 406 |
The content characteristics of the requested resource cannot meet the conditions in the request header, so a response entity cannot be generated. Unless it is a HEAD request, the response should return an entity containing a list of entity characteristics and addresses from which the user or browser can choose the most suitable one. The format of the entity is determined by the media type defined in the Content-Type header. Browsers can make the best choice based on the format and their own capabilities. However, the specification does not define any standard for making such automatic choices. |
| 407 |
Similar to a 401 response, except that the client must authenticate with the proxy server. The proxy server must return a Proxy-Authenticate header for authentication challenge. The client can return a Proxy-Authorization 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 may submit this request again at any time without any changes. |
| 409 |
The request could not be completed due to a conflict with the current state of the requested resource. This code is only allowed in situations where the user is expected to be able to resolve the conflict and resubmit the request. The response should include sufficient information for the user to discover the source of the conflict. Conflicts usually occur in the processing of PUT requests. For example, in an environment with version checking, if a PUT request to modify a specific resource carries version information that conflicts with a previous request from a third party, the server should return a 409 error, informing the user that the request cannot be completed. At this point, the response entity is likely to contain a comparison of the differences between the two conflicting versions, so that the user can resubmit a merged new version. |
| 410 |
The requested resource is no longer available on the server and there is no known forwarding address. This condition 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 condition 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, informing users that the resource is no longer available, and that the server owner wants all remote links pointing to this resource to be deleted. Such events are common in time-limited and value-added services. Similarly, the 410 response is also used to inform the client that on the current server site, resources originally belonging to an individual are no longer available. Of course, whether to mark all permanently unavailable resources as '410 Gone' and how long to maintain this mark depends entirely on the server owner. |
| 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 can submit the request again. |
| 412 |
The server, while verifying the preconditions given in the request header fields, failed to meet one or more of them. This status code allows the client to set preconditions in the request's meta-information (request header field data) when obtaining a resource, thereby preventing the request method from being applied to resources other than those intended. |
| 413 |
The server refuses to process the current request because the size of the entity data submitted by the request exceeds the range the server is willing or able to handle. In this case, the server may close the connection to prevent the client from continuing to send the request. If this condition is temporary, the server should return a Retry-After response header to inform the client how long to wait before retrying. |
| 414 |
The URI requested is longer than the server can interpret, so the server refuses to service the request. This is relatively rare, with typical situations including: a form submission that should have used the POST method becomes a GET method, causing the query string to be too long. Redirect URI \"black hole,\" for example, each redirect includes the old URI as part of the new URI, causing the URI to become too long after several redirects. The client is attempting to exploit security vulnerabilities in some servers. Such servers use fixed-length buffers to read or manipulate the request URI, and when the parameters after GET exceed a certain value, a buffer overflow may occur, leading to arbitrary code execution [1]. Servers without 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 requested resource and method, so the request is rejected. |
| 416 |
If the request includes a Range header, and none of the data ranges specified in Range overlap with the available range of the current resource, and the request does not include an If-Range header, then the server should return a 416 status code. If the Range uses byte ranges, this means that the first byte position of all requested data ranges exceeds the length of the current resource. The server should also include a Content-Range entity header when returning a 416 status code to indicate the length of the current resource. This response is also prohibited from using multipart/byteranges as its Content-Type. |
| 417 |
The expectation given in the Expect request header could not be met by the server, or the server is a proxy server that has clear evidence that the expectation cannot be met at the next node on the current route. |
| 421 |
The number of connections from the client's IP address to the server exceeds the maximum range allowed by the server. Usually, the IP address here refers to the client address seen by the server (such as the user's gateway or proxy server address). In this case, the calculation of the number of connections may involve more than one end user. |
| 422 |
The number of connections from the client's IP address to the server exceeds the maximum range allowed by the server. Usually, the IP address here refers to the client address seen by the server (such as the user's gateway or proxy server address). In this case, the calculation of the number of connections may involve more than one end user. |
| 422 |
The request was well-formed but could not 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 in a previous request, such as PROPPATCH. (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 |
Extended by Microsoft, indicating that the request should be retried after performing appropriate actions. |
| 500 |
The server encountered an unexpected condition that prevented it from fulfilling the request. Generally, this problem occurs when the server's program code has an error. |
| 501 |
The server does not support a function required by the current 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 when attempting to fulfill the request. |
| 503 |
The server is currently unable to handle the request due to temporary server maintenance or overload. This condition is temporary and will recover after some time. If the delay time can be estimated, 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 in the same way 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 want to refuse client connections. |
| 504 |
The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server (the server identified by the URI, e.g., HTTP, FTP, LDAP) or an auxiliary server (e.g., DNS). Note: Some proxy servers may return a 400 or 500 error when a DNS query 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 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 |
Extended by the Transparent Content Negotiation Protocol (RFC 2295), indicating that the server has an internal configuration error: the requested negotiated variant resource is configured to use itself in transparent content negotiation, thus it is not a suitable 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 |
The server has reached its bandwidth limit. This is not an official status code, but it is widely used. |
| 510 |
The policy required to obtain the resource has not been satisfied. (RFC 2774) |