When a visitor accesses a webpage, the visitor's browser sends a request to the server where the webpage is located. Before the browser receives and displays the webpage, the server will return a server header containing an HTTP status code to respond to the browser's request.
The English term for HTTP status code is "HTTP Status Code." Here are some common HTTP status codes:
HTTP status codes consist of three decimal numbers, with the first defining the type of status code, and the last two numbers do not have a classifying function. HTTP status codes are divided into 5 types:
| Classification | Description |
|---|---|
| 1** | Information, the server has received the request and the requester needs to continue the operation |
| 2** | Success, the operation was successfully received and processed |
| 3** | Redirection, further action is required to complete the request |
| 4** | Client error, the request contains a syntax error or the request cannot be completed |
| 5** | Server error, an error occurred in the server while processing the request |
| Status Code | English Name of Status Code | Chinese Description |
|---|---|---|
| Status Codes Starting with 1 | ||
| 100 | Continue | Continue. The client should continue its request |
| 101 | Switching Protocols | Switching Protocols. The server switches protocols based on the client's request. It can only switch to a higher-level protocol, such as switching to a newer version of the HTTP protocol |
| Status Codes Starting with 2 | ||
| 200 | OK | Request successful. Generally used for GET and POST requests |
| 201 | Created | Created. The request was successfully received 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 was successful. However, the meta information returned is not from the original server but from a copy |
| 204 | No Content | No Content. The server successfully processed the request but did not return any content. When the webpage is not updated, it can ensure that the browser continues to display the current document |
| 205 | Reset Content | Reset Content. The server successfully processed the request, and the user terminal (such as the 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 a partial GET request |
| Status Codes Starting with 3 | ||
| 300 | Multiple Choices | Multiple Choices. The requested resource may include multiple locations, and the response can return a list of resource characteristics and addresses for the user terminal (such as the browser) to choose from |
| 301 | Moved Permanently | Moved Permanently. The requested resource has been permanently moved to a new URI, and the returned information will include the new URI, and the browser will automatically redirect to the new URI. Any new requests should use the new URI instead in the future |
| 302 | Found | Found. Similar to 301. But the resource is only temporarily moved. The client should continue to use the original URI |
| 303 | See Other | See Other. Similar to 301. Use GET and POST requests to view |
| 304 | Not Modified | Not Modified. The requested resource has not been modified, and the server does not return any resources when returning this status code. The client usually caches the accessed resources and provides a header indicating that the client only wants to return resources modified after a specified date |
| 305 | Use Proxy | Use Proxy. The requested resource must be accessed through a proxy |
| 306 | Unused | A deprecated HTTP status code |
| 307 | Temporary Redirect | Temporary Redirect. Similar to 302. Use GET requests for redirection |
| Status Codes Starting with 4 | ||
| 400 | Bad Request | Bad Request. The client's request has a syntax error, and the server cannot understand it |
| 401 | Unauthorized | The request requires user authentication |
| 402 | Payment Required | Reserved for future use |
| 403 | Forbidden | The server understood the request but refuses to authorize it |
| 404 | Not Found | The server can't find the requested resource (web page). This code can be used to set a custom "resource not found" page for web designers |
| 405 | Method Not Allowed | The method specified in the request is not allowed for the resource identified by the request URI |
| 406 | Not Acceptable | The server cannot generate a response that matches the list of acceptable values defined in the producible headers from the client's request |
| 407 | Proxy Authentication Required | Similar to 401, but authentication is needed to be done through a proxy |
| 408 | Request Time-out | The server timed out waiting for the client to send a request |
| 409 | Conflict | A conflict happened when the server tried to fulfill a PUT request |
| 410 | Gone | The requested resource 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. Upon receiving a 410 status code, the client should not request the resource in the future. Clients should also not cache a 410 response |
| 411 | Length Required | The server refuses to accept the request without a defined Content-Length |
| 412 | Precondition Failed | One or more conditions given in the request header fields evaluated to false when tested on the server |
| 413 | Request Entity 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 |
| 414 | Request-URI Too Large | The URI provided was too long for the server to process |
| 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 serve the requested bytes |
| 417 | Expectation Failed | The expectation given in the request's Expect header field could not be met by the server |
| 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, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request |
| 503 | Service Unavailable | The server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay |
| 504 | Gateway Time-out | The server, while acting as a gateway or proxy, did not receive a timely response from an upstream server it needed in order to complete the request |
| 505 | HTTP Version not supported | The server does not support, or refuses to support, the HTTP protocol version that was used in the request message |
| Status Code | Meaning |
|---|---|
| 100 | The client should continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server |
| 101 | The server understands the type of the request and will switch to a different protocol as requested, or to a protocol with the same major version number, and will send a response with the protocol switch information |
| 102 | A WebDAV extension to the HTTP protocol, this status code indicates that the server has received and is processing the request, but no response is available yet |
| 200 | Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request, the response will contain an entity describing or containing the result of the action |
| 201 | A request to create a new resource has been fulfilled, resulting in the creation of a new resource, and a new URI has been generated for that resource. The URI is included in the response so that it can be referenced in future requests |
| 202 | The server has accepted the request but has not yet processed it. As it may be rejected, the final request may or may not be executed. In the case of asynchronous operations, there is no more convenient way to send this status code. The purpose of the response returning the 202 status code is to allow the server to accept requests from other processes (such as batch operations that are only executed once a day) without having to keep the client connected to the server until all batch operations are completed. The response that accepts the request processing and returns the 202 status code should include some information indicating the current processing status in the returned entity, as well as a pointer to the processing status ** 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 metadata is not a valid set on the original server, but comes from 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 lead to the original server knowing the superset of metadata. The use of this status code is not mandatory, and it is only appropriate when the response would return a 200 OK without using this status code. |
| 204 | The server has successfully processed the request, but there is no need to return any entity content, and it wants to return updated metadata. The response may return new or updated metadata in the form of entity headers. If there is this header information, it should correspond to the requested variable. If the client is a browser, then the user's browser should keep the page that sent the request, without any changes to the document view, even if the new or updated metadata should be applied to the document in the user's browser's active view according to the specification. Since the 204 response is prohibited from containing any message body, it always ends with the first blank line after the message header. |
| 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 accept user input and immediately reset the form 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 message header. |
| 206 | The server has successfully processed a partial GET request. Similar to HTTP download tools such as FlashGet or Xunlei, this type of response is used to implement breakpoint resumption or to break down a large document into multiple download segments for simultaneous download. This request must include a Range header to indicate the content range that the client wants to get, and may include an 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 range of content for this segment. If the response includes Content-Length, then its value must match the actual byte count of the content range returned. Date ETag and/or Content-Location, if the same request should return a 200 response. Expires, Cache-Control, and/or Vary, if their values may differ from the values corresponding to other responses for the same variable. If this response request used If-Range strong cache validation, then this response should not include other entity headers; if this response's request used If-Range weak cache validation, then this response is prohibited from including other entity headers; this avoids inconsistency between the cached entity content and the updated entity header information. Otherwise, this response should include all the entity header fields that should be returned in a 200 response. If the ETag or Last-Modified headers cannot match precisely, then the client cache should prohibit combining the content returned by the 206 response with any previously cached content. Any cache that does not support the Range and Content-Range headers should prohibit caching the content returned by the 206 response. |
| 207 | A status code extended by WebDAV (RFC 2518), representing that the subsequent message body will be an XML message, and may contain a series of ** response codes according to the number of previous sub-requests. |
| 300 | The requested resource has a series of choices for feedback information, each with its own specific address and browser-driven negotiation information. Users or browsers can choose a preferred address for redirection. Unless this is a HEAD request, the response should include an entity of a list of resource characteristics and addresses so that users or browsers can choose 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 the browser's own capabilities. Of course, the RFC 2616 specification does not stipulate how such automatic selection should be carried out. If the server itself already has a preferred feedback choice, it should be indicated in the Location field; browsers may take this Location value as the address for automatic redirection. In addition, unless specified otherwise, 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 URIs returned in this response. If possible, clients with link editing capabilities should automatically modify the requested 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 this is a HEAD request, the entity of the response should contain hyperlinks pointing 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 the user confirms, because the conditions of the request may change. Note: For some browsers using the HTTP/1. protocol, when they send a POST request and get a 301 response, the subsequent redirection request will become a GET method. |
| 302 | The requested resource is now temporarily responding to requests from a different URI. Since such redirection is temporary, clients 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 entity of the response should contain hyperlinks pointing to the new URI and a brief description. If this is not a GET or HEAD request, then the browser is prohibited from automatically redirecting unless the user confirms, because the conditions of the request may change. Note: Although RFC 1945 and RFC 2068 specifications do not allow clients to change the request method when redirecting, 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 kind of response the server expects from the client. |
| 303 | The response corresponding to the current request can be found on another URI, and the client should access that resource using the GET method. The existence of this method is mainly to allow POST requests activated by scripts to output redirection to a new resource. This new URI is not a substitute reference for the original resource. At the same time, the 303 response is 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 entity of the response should contain hyperlinks pointing to the new URI and a brief description. Note: Many browsers before the HTTP/1.1 version cannot correctly understand the 303 status. 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 specification requires the client to handle 303 responses. |
| 304 | If the client sends a conditional GET request and the request is 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. The 304 response is prohibited from including a message body, so it always ends with the first blank line after the message header. This response must include the following header information: Date, unless the server does not have a clock. If the server without a clock also follows these rules, then proxy servers and clients can add the Date field to the received response header by themselves (as stipulated 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 be different from the values corresponding to other responses with the same variable. If this response request used strong cache validation, then this response should not include other entity headers; otherwise (for example, a conditional GET request with weak cache validation), this response is prohibited from including other entity headers; this avoids inconsistencies between the cached entity content and the updated entity header information. If a 304 response indicates that the current entity is not cached, then the caching system must ignore this response and resend a request without restrictions. If a 304 response is received that requires updating a cached entry, then the caching system must update the entire entry to reflect the values of all fields updated in the response. |
| 305 | 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. |
| 305 | Note: RFC 2068 does not explicitly state that the 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 | 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 redirection is temporary, the client should continue to send subsequent 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 response's Location field. Unless this is a HEAD request, the response entity should include a hyperlink pointing to the new URI and a brief explanation. Because some browsers cannot recognize the 307 response, it is necessary to add the above information so that users can understand and make access requests to the new URI. If this is not a GET or HEAD request, then the browser is prohibited from automatically redirecting unless confirmed by the user, as the conditions of the request may change. |
| 400 | 1. There is a semantic error, the current request cannot be understood by the server. The client should not repeat this request unless it is modified. 2. The request parameters are incorrect. |
| 401 | The current request requires user authentication. This response must include a WWW-Authenticate header suitable for the requested resource to inquire about user information. The client can repeat a request containing the appropriate Authorization header. If the current request already contains an Authorization certificate, then the 401 response represents 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 authentication at least once, then the browser should present the entity information contained in the response to the user, as this entity information may contain relevant diagnostic information. See RFC 2617. |
| 402 | This status code is reserved for potential 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 hopes to explain why the request cannot be executed, it should describe the reason for refusal in the entity. Of course, the server can also return a 404 response if it does not want to let the client obtain any information. |
| 404 | The request failed, the resource requested was not found on the server. There is no information to 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 has been permanently unavailable due to some internal configuration mechanism, and there is 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 there is no other suitable response available. |
| 405 | The request method specified in the request line cannot be used for the corresponding resource. This response must return an Allow header to indicate the list of request methods that the current resource can accept. Given that PUT, DELETE ** perform write operations on the server's resources, most web servers do not support or do not allow the above request methods by default. For such requests, a 405 error is returned. |
| 406 | The content characteristics of the requested resource cannot 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 containing a list of entity characteristics and addresses that the user or browser can select from. 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 standard 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 for identity inquiry. The client can return a Proxy-Authorization header for verification. See RFC 2617. |
| 408 | Request timeout. The client did not complete the sending of a request within the time the server was ready to wait. The client can submit this request again at any time without any changes. |
| 409 | Due to a conflict with the current state of the requested resource, the request cannot be completed. This code can only be used in such a situation: the user is considered able to resolve the conflict and will resubmit a new request. The response should contain enough information for the user to find the source of the conflict. Conflicts usually occur in the processing of PUT requests. For example, in an environment with version checking, if the version information attached to a specific resource modification request submitted by PUT conflicts with a previous (third-party) request, then 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, 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. Such a 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, then the 404 status code should be used. Unless otherwise indicated, this response is cacheable. The purpose of the 410 response is mainly to help website administrators maintain the website, notify 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 time-limited, value-added services. Similarly, the 410 response is also used to notify clients that the resources originally belonging to an individual on the current server site are no longer available. Of course, whether to mark all permanently unavailable resources as '410 Gone', and whether to keep this mark for how long, 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 could not meet one or more of the preconditions given in the request's header fields when it was validating them. This status code allows the client to set preconditions in the metadata of the request (data in the request header fields) when obtaining a resource, to avoid applying the request method to resources other than the desired content. |
| 413 | The server refuses to process the current request because the size of the entity data submitted with the request exceeds the range that the server is willing or able to process. In this case, the server can 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 how much time to wait before trying again. |
| 414 | The length of the requested URI exceeds the length that the server can interpret, so the server refuses to provide service for this request. This is relatively rare and usually includes the following situations: The form submission that should have used the POST method has become a GET method, resulting in a query string that is too long. Redirect URI "black hole", for example, each redirection takes the old URI as part of the new URI, causing the URI to be too long after several redirections. The client is trying to exploit some security vulnerabilities in the server. Such servers use a fixed-length buffer to read or operate on the request URI, and when the parameters after GET exceed a certain value, it may cause a buffer overflow, 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 current request method and the requested resource, so the request is refused. |
| 416 | If the request includes a Range request header and none of the data ranges specified in the Range overlap with the current resource's available range, and there is no If-Range request header defined in the request, then the server should return a 416 status code. If the Range uses a byte range, this situation means that the first byte position of all the data ranges specified in the request exceeds the length of the current resource. The server should also include a Content-Range entity header in the 416 status code response 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 Expect request header cannot be met by the server, or the server is a proxy server, and it has clear evidence that the content of Expect cannot be met at the next node in the current route. |
| 421 | The number of connections from the current client's IP address to the server exceeds the maximum range permitted by the server. Usually, the IP address here refers to the client address seen from the server (such as the user's ** 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 current client's IP address to the server exceeds the maximum range permitted by the server. Usually, the IP address here refers to the client address seen from the server (such as the user's ** or proxy server address). In this case, the calculation of the number of connections may involve more than one end user. |
| 422 | The request format is correct, but due to semantic errors, it cannot be responded to. (RFC 4918 WebDAV) 423 Locked The current resource is locked. (RFC 4918 WebDAV) |
| 424 | Due to an error in a previous request, the current request failed, such as PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Defined in the WebDav Advanced Collections draft, but not in the "WebDAV Order Set Protocol" (RFC 3658). |
| 426 | The client should switch to TLS/1.. (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 issue occurs when there is an error in the server's program code. |
| 501 | The server does not support the functionality required for the current request. When the server cannot recognize the method of the request and cannot support any requests for resources. |
| 502 | As a gateway or proxy server working, it received an invalid response from the upstream server when trying to execute the request. |
| 503 | Due to temporary server maintenance or overload, the server is currently unable to process the request. This situation is temporary and will recover after a period of time. If the delay time can be expected, a Retry-After header can be included in the response to indicate this delay time. If this Retry-After information is not given, then the client should handle it in the same way as handling a 500 response. Note: The existence of the 503 status code does not mean that the server must use it when it is overloaded. Some servers just want to refuse the client's connection. |
| 504 | As a gateway or proxy server working, it did not receive a response in time from the upstream server (the server identified by URI, such as HTTP, FTP, LDAP) or auxiliary server (such as DNS) when trying to execute the request. Note: Some proxy servers may return a 400 or 500 error when the 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 is unwilling to use the same version as the client. The response should include an entity that describes why the version is not supported and which protocols the server supports. |
| 506 | Extended by the Transparent Content Negotiation Protocol (RFC 2295), it represents an internal configuration error in the server: the requested negotiated variant resource is configured to use itself in transparent content negotiation, and therefore is not a suitable focus in a negotiation process. |
| 507 | The server cannot store the content required to complete the request. This situation is considered temporary. WebDAV (RFC 4918) |
| 509 | The server has reached the bandwidth limit. This is not an official status code, but it is still widely used. |
| 510 | The policy required to obtain the resource has not been satisfied. (RFC 2774) |