| Код состояния HTTP | Status code meaning |
|---|
| 100 | The client side should continue to send requests. This temporary response is used to inform the client side that some of its requests have been received by the server and have not been rejected. The client side should continue to send the rest of the request, or ignore the response if the request has been completed. The server must send a final response to the client side after the request is completed. |
| 101 | The server has understood the client's request and will inform the client side through the Upgrade header to use a different protocol to complete the request. After sending the last blank line in the response, the server will switch to those protocols defined in the Upgrade header. Similar measures should only be taken when switching to a new protocol is more beneficial. For example, switching to a new HTTP version has advantages over an old version, or switching to a real-time and synchronous protocol to deliver resources that take advantage of such features. |
| 102 | The status code extended by WebDAV (RFC 2518) indicates that processing will continue. |
| 200. | The request was successful, and the desired response headers or data bodies are returned with the response. |
| 201 | The request has been fulfilled, and a new resource has been created based on the requirements of the request, and its URI has been returned with 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 it has not yet processed it. Just as it may be rejected, the request may or may not be executed eventually. In the case of asynchronous operations, there is no more convenient way to do this than to send this status code. The purpose of returning a 202 status code response is to allow the server to accept requests from other processes (such as a batch-based operation that is performed only once a day) without having to keep the client side connected to the server until the batch operation is complete. In response to accepting a request for processing and returning a 202 status code, the returned entity should include some information indicating the current state of the process, as well as a pointer to the process status monitor or status prediction, so that the user can estimate whether the operation has completed. |
| 203 | The server has successfully processed the request, but the returned entity header meta information is not a valid deterministic set on the origin server, but is a local or third-party copy. The current information may be a subset or superset of the original version. For example, metadata containing resources may cause the origin server to know the meta super. Using this status code is not required, and is only appropriate if the response returns 200 OK without this status code. |
| 204 | The server successfully processed the request, but does not need to return any physical content, and wishes to return updated meta information. The response may be in the form of an entity header, returning new or updated meta information. If this header information exists, it should correspond to the requested variable. If the client side is a browser, then the user browser should keep the page that sent the request without any changes to the document view, even if the new or updated meta information should be applied to the document in the active view of the user browser according to the specification. Since the 204 response is prohibited from including any message body, it always ends with the first blank line after the header. |
| 205 | The server successfully processed the request and returned nothing. But unlike the 204 response, the response that returns this status code requires the requester to reset the document view. This response is primarily used to reset the form immediately after accepting user input so that the user can easily start another input. Like the 204 response, this response is also prohibited from including any message body and ends with the first blank line after the header. |
| 206 | The server has successfully processed part of the GET request. HTTP download tools like FlashGet or Xunlei use this type of response to implement a breakpoint continuation or to break up a large document into multiple download segments to download simultaneously. The request must contain a Range header to indicate the range of content the client side wants, and may include If-Range as a request condition. The response must contain the following header fields: Content-Range to indicate the range of content returned in this response; if it is a multi-segment download with Content-Type multipart/byteranges, each multipart segment should contain a Content-Range field to indicate the content range of this segment. If the response contains Content-Length, then its value must match the actual number of bytes in the content range it returns. Date ETag and/or Content-Location, if the same request should have returned a 200 response. Expires, Cache-Control, and/or Vary, if its value may be different from the value corresponding to other responses to the same variable before. If this response request uses If-Range strong cache validation, then this response should not include other entity headers; if this response request uses If-Range weak cache validation, then this response should not include other entity headers; this avoids inconsistencies between cached entity content and updated entity header information. Otherwise, this response should contain all entity header fields that should be returned in a 200 response. If the ETag or Last-Modified headers do not match exactly, the client side cache should prohibit combining the content returned in the 206 response with any previously cached content. Any cache that does not support Range and the Content-Range header is prohibited from caching the content returned by the 206 response. |
| 207 | A status code extended by WebDAV (RFC 2518) represents that the body of the subsequent message 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 range of feedback options, each with its own specific address and browser-driven negotiation information. The user or browser can choose a preferred address for redirection. Unless this is a HEAD request, the response should include an entity with a list of resource attributes and addresses from which the user or browser can choose the most appropriate redirect address. The format of this entity is determined by the format defined by Content-Type. The browser may automatically make the most appropriate choice based on the format of the response and the browser's own capabilities. Of course, the RFC 2616 specification does not specify how such automatic selection should be performed. If the server itself already has a preferred feedback selection, the URI of the feedback should be specified in the Location; browsers may use this Location value as the address for automatic redirection. In addition, unless otherwise specified, the response is also cacheable. |
| 301 | The requested resource has been permanently moved to a new location, and any future reference to this resource should use one of several URIs returned by this response. If possible, the client side with link editing capabilities should automatically change the requested address to the address returned from 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 hyperlinke 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 confirmed by the user, as the conditions of the request may change as a result. Note: For some browsers using the HTTP/1.0 protocol, when they send a POST request and get a 301 response, the subsequent redirect request will be GET. |
| 302 | The requested resource is now temporarily responding to the request from a different URI. Since such redirects are temporary, the client side 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 field of the response. Unless this is a HEAD request, the response entity should contain a hyperlinke to the new URI and a brief description. If this is not a GET or HEAD request, the browser prohibits automatic redirection unless confirmed by the user, as the conditions of the request may change as a result. Note: Although the RFC 1945 and RFC 2068 specifications do not allow the client side to change the method of the request when redirecting, many existing browsers treat the 302 response as a 303 response and use GET to access the URI specified in the Location, ignoring the original request method. Status codes 303 and 307 were added to clarify what the server expects from the client side. |
| 303 | The response to the current request can be found on another URI, and the client side should GET access to that resource. This method exists primarily to allow script-activated POST request output to be redirected to a new resource. This new URI is not a substitute reference to the original resource. Also, 303 responses are prohibited from being cached. Of course, a second request (redirect) 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 hyperlinke to the new URI and a brief description. Note: Many browsers prior to HTTP/1.1 do not understand 303 status correctly. If you need to consider interaction with these browsers, the 302 status code should be sufficient, because most browsers handle 302 responses in exactly the way the above specification requires the client side to handle 303 responses. |
| 304 | If the client side sends a conditional GET request and the request has been allowed, and the content of the document has not changed (since the last visit or according to the conditions of the request), the server should return this status code. 304 responses are prohibited from including message bodies, so always end with the first blank line after the header. The response must contain the following header information: Date, unless this server has no clock.
If the server without a clock also follows these rules, then the proxy server and client side can add the Date field to the received response header by themselves (as specified in RFC 2068), and the caching mechanism will work fine. ETag and/or Content-Location, if the same request should have returned a 200 response. Expires, Cache-Control, and/or Vary, if its value may be different from the value corresponding to other responses to the same variable before.
If this response request uses strong cache validation, then this response should not include other entity headers; otherwise (for example, a conditional GET request uses 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 an entity is not currently cached, the caching system must ignore the response and send repeated requests without restrictions.
If a 304 response is received to update a cached entry, the caching system must update the entire entry to reflect the values of all fields that were updated in the response. |
| 305 | The requested resource must be accessed through the specified proxy. The URI information of the specified proxy is given in the Location field. The receiver needs to repeatedly send a separate request to access the corresponding resource through this proxy. Only the origin server can establish a 305 response. Note: There is no explicit 305 response in RFC 2068 to redirect a single request, and it 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 now temporarily responding to the request from a different URI. Since such redirects are temporary, the client side 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 responding entity should contain a hyperlinke pointing to the new URI and a brief description. Since some browsers do not recognize the 307 response, the above information needs to be added so that the user can understand and request access to the new URI.
If this is not a GET or HEAD request, then the browser prohibits automatic redirection unless confirmed by the user, as the request's conditions may change as a result. |
| 400 | 1. The semantics are wrong, and the current request cannot be understood by the server. Unless modified, the client side should not submit the request repeatedly. 2. The request parameters are wrong. |
| 401 | The current request requires user authentication. The response must contain a WWW-Authenticate header for the requested resource to ask the user for information. The client side can resubmit a request with the appropriate Authorization header information. If the current request already contains Authorization certificates, then the 401 response represents that the server has rejected those certificates. If the 401 response contains the same authentication query as the previous response, and the browser has attempted authentication at least once, then the browser should show the user 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 refused to execute it. Unlike a 401 response, authentication does not help, and the request should not be repeated. If this is not a HEAD request, and the server wants to be able to explain why the request cannot be executed, then the reason for the rejection should be described within the entity. Of course, the server can also return a 404 response if it does not want the client side to get any information. |
| 404 | The request failed, and the desired resource was not found on the server. There is no information to tell the user whether the condition is temporary or permanent. If the server is aware of the situation, the 410 status code should be used to inform the old resource that it is permanently unavailable due to some internal configuration mechanism and has no address to jump to. The 404 status code is widely used when the server does not want to reveal why the request was rejected or no other suitable response is available. |
| 405 | The request method specified in the request line cannot be used to request the corresponding resource. The response must return an Allow header indicating a list of request methods that can be accepted by the current resource. Since PUT and DELETE methods write to resources on the server, most web servers do not support or do not allow the above request method by default, and will return a 405 error for such requests. |
| 406 | The content characteristics of the requested resource do not meet the conditions in the request header, so a response entity cannot be generated. Unless this is a HEAD request, the response should return an entity that allows the user or browser to select the most appropriate entity characteristics and address list. The format of the entity is determined by the media type defined in the Content-Type header. The browser can make the best choice based on the format and its own capabilities. However, the specification does not define any criteria for making such automatic selections. |
| 407 | Similar to the 401 response, except that the client side must authenticate on the proxy server. The proxy server must return a Proxy-Authenticate for authentication. The client side can return a Proxy-Authorization header for authentication. See RFC 2617. |
| 408 | Request timed out. The client side did not complete the sending of a request within the time the server was ready to wait. The client side can resubmit the request at any time without any changes. |
| 409 | The request cannot be completed due to a conflict with the current state of the requested resource. This code is only allowed to be used if the user is assumed to be able to resolve the conflict and will resubmit a new request. The 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-checked environment, if the version information attached to a PUT-submitted modification request for a particular resource conflicts with a previous (third-party) request, the server should return a 409 error informing the user that the request could not be completed.
At this point, the response entity is likely to contain a comparison of differences between the two conflicting versions, so that the user can resubmit the merged version. |
| 410 | The requested resource is no longer available on the server and does not have any known forwarding address. This condition should be considered permanent. If possible, the client side with link editing capabilities should remove all references to this address with the user's permission. If the server does not know or cannot determine whether this condition is permanent, then a 404 status code should be used. Unless otherwise specified, this response is cacheable. The purpose of the 410 response is primarily to help the webmaster maintain the website, to inform the user that the resource is no longer available, and that the server owner wants all remote connections to this resource to be deleted.
This type of event is common in time-limited, value-added services. Similarly, the 410 response is used to inform the client side that resources originally belonging to an individual are no longer available on the current server site. Of course, it is entirely up to the server owner whether to mark all permanently unavailable resources as' 410 Gone ', and how long to keep this mark. |
| 411 | The server refuses to accept the request without defining a Content-Length header. After adding a valid Content-Length header indicating the length of the request body, the client side can submit the request again. |
| 412 | The server failed to meet one or more of the prerequisites when verifying that they were given in the header field of the request. This status code allows the client side to set prerequisites in the requested metadata (request header field data) when fetching resources, thus preventing the request method from being applied to resources other than what it wants. |
| 413 | The server refuses to process the current request because the request submits more entity data than the server is willing or able to handle. In this case, the server can close the connection to prevent the client side from continuing to send the request. If this situation is temporary, the server should return a Retry-After response header to inform the client side how much time it can try again. |
| 414 | The requested URI is longer than the server can interpret, so the server refuses to service the request. This is rare, and common cases include: A form submission that should have used the POST method becomes a GET method, causing the query string (Query String) to be too long. Redirect URI "black holes", such as each redirect using the old URI as part of the new URI, resulting in the URI being too long after several redirects. The client is trying to attack the server with security bugs that exist in some servers.
This type of server uses a fixed-length buffer to read or manipulate the requested URI. When the parameters after GET exceed a certain value, a buffer overflow may occur, resulting in arbitrary code execution [1]. Servers without such vulnerabilities should return a 414 status code. |
| 415 | For the method of the current request and the requested resource, the entity submitted in the request is not in a format supported by the server, so the request is rejected. |
| 416 | If the request contains a Range header, and any data ranges specified in the Range do not coincide with the available range of the current resource, and the If-Range header is not defined in the request, the server should return a 416 status code. If the Range uses a byte range, then this situation means that the first byte position of all data ranges specified by the request exceeds the length of the current resource. The server should also include a Content-Range entity header along with the 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 expected content specified in the request header Expect cannot be satisfied by the server, or the server is a proxy server that has clear evidence that the expected content cannot be satisfied on the next node of the current route. |
| 421 | The number of connections to the server from the Internet Protocol Address where the current client side is located exceeds the maximum allowed by the server. Typically, the Internet Protocol Address here refers to the client side address seen from the server (such as the user's gateway or proxy server address). In this case, the connection count may involve more than one end user. |
| 422 | The number of connections to the server from the Internet Protocol Address where the current client side is located exceeds the maximum allowed by the server. Typically, the Internet Protocol Address here refers to the client side address seen from the server (such as the user's gateway or proxy server address). In this case, the connection count may involve more than one end user. |
| 422 | The request was formatted correctly, but could not be responded to due to a semantic error. (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 in the WebDAV Sequential Set Protocol (RFC 3658). |
| 426 | The client side should switch to TLS/1.0. (RFC 2817) |
| 449 | Extended by Microsoft, requests should be retried after performing the appropriate action. |
| 500 | The server encountered an unexpected situation that prevented it from completing the request. Generally, this problem occurs when the server's code fails. |
| 501 | The server does not support a feature required by the current request. When the server cannot recognize the method requested and cannot support its request for any resource. |
| 502 | When a server working as a gateway or proxy attempts to execute a request, it receives an invalid response from an upstream server. |
| 503 | The server is currently unable to process requests due to temporary server maintenance or overload. This condition is temporary and will be restored after some time. If the delay time can be predicted, the response can include a Retry-After header to indicate the delay time. If this Retry-After information is not given, the client side should handle it as if it were a 500 response. Note: The existence of a 503 status code does not mean that the server must use it in the event of an overload. Some servers simply wish to deny the client's connection. |
| 504 | When a server working as a gateway or proxy attempts to execute a request, it fails to receive a response from an upstream server (identified by the URI, such as HTTP, FTP, LDAP) or a secondary server (such as DNS) in a timely manner. Note: Some proxy servers return a 400 or 500 error when the DNS query times out |
| 505 | The server does not support, or refuses to support, the version of HTTP used in the request. This implies that the server cannot or will not use the same version as the client side. 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), this represents an internal configuration error on the server: the requested negotiation variable resource is configured to use itself in a transparent content negotiation, and therefore is not an appropriate focus in a negotiation process. |
| 507 | Сервер не может сохранить содержимое, необходимое для выполнения запроса. Это условие считается временным. WebDAV (RFC 4918) |
| 509 | Сервер достиг предела пропускной способности. Это не официальный код состояния, но он все еще широко используется. |
| 510 | Политики, необход***е для получения ресурсов, не выполняются. (RFC 2774) |
