HTTP status code [all], come and take a look if you forget it!

This type of response is a temporary response, containing only the response line and some optional response header information, and ending with a blank line. Since no 1xx type status code is defined in the HTTP/1.0 protocol, the server is prohibited from sending 1xx type responses to the client except under certain experimental conditions. The responses represented by these status codes are informational and identify additional actions that the client should take.

100 Continue

The server has received the request headers and the client should continue sending the request body. For example, for POST type requests, the request body needs to be sent.

If the request has already been completed, ignore this response. The server must send a final response to the client after the request is completed. For the server to check the request headers, the client must send Expect: 100-continue as a request header in its initial request and receive a 100 Continue status code before sending the body. If the response status code is 417 Expectation Failed, it means that the request should not continue.

101 Switching Protocols

The server has understood the client's request and will notify the client through the Upgrade message header to use a different protocol to complete the request.

After sending the last blank line of this response, the server will switch to the protocols defined in the Upgrade header. Such measures should only be taken when switching to a new protocol is more beneficial. For example, switching to a new HTTP version, such as HTTP/2.0, has advantages over older versions, or switching to a real-time and synchronous protocol, such as WebSocket, to deliver resources that take advantage of such features.

102 Processing

A status code extended by the WebDAV (RFC 2518) request indicating that processing will continue.

A WebDAV request may contain many subrequests involving file operations, taking a long time to complete the request. This status code indicates that the server has received and is processing the request, but no response is available. This prevents clients from timing out and assuming requests are lost.

2xx type

This type of status code means that the request has been received, understood, and accepted.

200 OK

The request is successful and the expected response headers and response body are returned.

201 Created

The request has been fulfilled, a new resource has been created based on the request's needs, and its URI has been returned with the Location header. If the required resources cannot be created in time, 202 Accepted should be returned.

202 Accepted

The server accepted the request but has not yet processed it. The request may or may not ultimately be executed, and may be prohibited while processing occurs.

203 Non-Authoritative Information

(As of HTTP/1.1) The server is a transforming proxy, such as a network accelerator, that originates with the 200 OK status code, but responds with a modified version of the original response.

204 No Content

The server successfully processed the request and returned nothing.

205 Reset Content

The server successfully processed the request and returned nothing. Unlike the 204 No Content response, this response requires the requester to reset the document view.

206 Partial Content

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 resuming or to decompose a large document into multiple download segments for simultaneous downloading.

RFC 7233: Range Request
When only a partial response is obtained due to various factors, initiate a range request to obtain the remaining content to avoid wasting resources by requesting from the beginning.

207 Multi-State

The status code extended by the WebDAV (RFC 4918) request indicates 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 subrequests.

208 Already Reported

Status code used by WebDAV (RFC 5842) request extensions to indicate that the members of the DAV binding have been enumerated in the previous part of the multi-state response and have not been included again.

226 IM Used

The server has satisfied a request for a resource, represented by the results of one or more entity operations on the entity request.

RFC 3229

3xx type

This type of status code indicates that the client needs to take further action to complete the request.

Usually these status codes are used for redirection, and the subsequent request address, that is, the redirection target, is specified in the Location field of this response. As recommended by the HTTP/1.0 specification, browsers should not automatically access more than 5 redirects.

300 Multiple Choices

The requested resource has a series of optional responses, each with its own specific address and browser driver 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 choice, the URI of this feedback should be specified in Location; the browser may use this Location value as the address for automatic redirection. Additionally, this response is cacheable unless otherwise specified.

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 several URIs returned with this response.

If possible, clients with link editing capabilities should automatically modify 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 hyperlink 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, because the conditions of the request may change accordingly. Note: For some browsers using the HTTP/1.0 protocol, when the POST request they send gets a 301 Moved Permanently response, the subsequent redirect request will become a GET method.

302 Found

Ask the client to perform a temporary redirect. Because such redirects are 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 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 prohibits automatic redirection unless confirmed by the user, because the conditions of the request may change accordingly. Note: Although the RFC 1945 and RFC 2068 specifications do not allow the client to change the request method when redirecting, many existing browsers treat the 302 Found response as a 303 See Other response, and use the GET method to access the URI specified in the Location. , regardless of the originally requested method. Therefore, status codes 303 See Other and 307 Temporary Redirect 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. When a response is received in response to POST/PUT/DELETE, the client should assume that the server has received the data and should issue a redirect using a separate GET message.

This method exists primarily to allow the output of POST/PUT/DELETE requests initiated by scripts to be redirected to a new resource. This new URI is not a replacement reference to the original resource. At the same time, the 303 See Other response is prohibited from being cached. Of course, the second request (redirect) might 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 pre-HTTP/1.1 browsers do not correctly understand the 303 See Other status. If you need to consider interaction with these browsers, the 302 Found status code should be sufficient, because most browsers handle the 302 Found response exactly the way the above specification requires the client to handle the 303 See Other response.

304 Not Modified

Indicates that the resource has not been modified because of the version specified by the request header If-Modified-Since or If-None-Match. In this case, there is no need to retransmit the resource since the client still has the previously downloaded copy.

305 Use Proxy

The requested resource must be accessed through the specified proxy. The URI information of the specified proxy will be given in the Location field. The recipient needs to repeatedly send a separate request to access the corresponding resources through this proxy.

Only the origin server can create a 305 Use Proxy response. Many HTTP clients (such as Mozilla and Internet Explorer) do not properly handle responses with this status code, mainly for security reasons. Note: It is not clear from RFC 2068 that a 305 Use Proxy response is intended to redirect a single request and can only be established by the origin server. Ignoring these restrictions can lead to serious safety consequences.

306 Switch Proxy

In the latest version of the specification, the 306 status code is no longer used. Originally it meant "Subsequent requests should use the specified proxy".

307 Temporary Redirect

In this case, the request should be repeated with another URI, but subsequent requests should still use the original URI. Contrary to 302 Found, changes to the request method are not allowed when the original request is reissued. For example, a POST request should be repeated with another POST request.

308 Permanent Redirect

request and all future requests should be repeated using another URI. 307 Temporary Redirect and 308 Permanent Redirect duplicate the behavior of 302 Found and 301 Moved Permanently, but do not allow HTTP method changes. For example, submitting a form to a permanently redirected resource might go smoothly.

RFC 7538

4xx type

This type of status code means that the client seems to have encountered an error that is preventing the server from processing.

Unless the response is a HEAD request, the server SHOULD return an entity explaining the current error condition and whether it is temporary or permanent. These status codes apply to any request method. Browsers should display any entity content contained in such error responses to the user. If the client is transmitting data when the error occurs, server implementations using TCP should carefully ensure that the client has received the packet containing the error information before closing the connection between the client and the server. If the client continues to send data to the server after receiving the error message, the server's TCP stack will send a reset packet to the client to clear all the client's unrecognized input buffers to prevent these data from being used by the server. The application reads and interferes with the latter.

400 Bad Request

The server cannot or will not handle the request due to an obvious client error, such as the wrong way to request it.

401 Unauthorized

This status code indicates that the current request requires user authentication.

RFC 7235

402 Payment Required

This status code is reserved for possible future needs.

The original intention of this status code may be to be used as part of some form of digital cash or online payment scheme, but few providers use it, and this status code is generally not used. The Google Developers API uses this status code if a specific developer has exceeded the daily limit of requests.

403 Forbidden

Although the user identity authentication is successful and the server has understood the request, the user lacks the corresponding access rights and the server refuses to execute the request.

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 in the entity. Of course, the server can also return a 404 Not Found response if it does not want the client to obtain any information.

404 Not Found

Request failed. The requested resource is not found on the server, but subsequent requests from the user are allowed.

The 404 Not Found 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 Method Not Allowed

The request method specified in the request line cannot be used to request the corresponding resource. The response must return an Allow header information to indicate the list of request methods that the current resource can accept.

For example, a GET request on a form that needs to render data via POST, or a PUT request on a read-only resource. Since the PUT and DELETE methods will write resources on the server, most web servers do not support or do not allow the above request methods under the default configuration. For such requests, a 405 Method Not Allowed error will be returned.

406 Not Acceptable

The request is unacceptable because the content characteristics of the requested resource do not satisfy the conditions in the request header and therefore the response entity cannot be generated.

Unless this is a HEAD request, the response should return an entity containing a list of entity attributes and addresses from which the user or browser can choose the most appropriate. The format of the entity is determined by the media type defined in the Content-Type header. The browser can make its own best choice based on the format and its capabilities. However, the specification does not define any criteria for making such automatic selections.

407 Proxy Authentication Required

Similar to the 401 Unauthorized response, except the client must authenticate with the proxy server. The proxy server must return a Proxy-Authenticate for identity query. The client can return a Proxy-Authorization header for verification.

RFC 2617

408 Request Timeout

Request timed out. According to the HTTP specification, if the client does not complete sending a request within the time that the server is prepared to wait, the client can resubmit the request at any time without making any changes.

409 Conflict

Indicates that the request cannot be processed because there is a conflict in the request, such as an editing conflict between multiple synchronized updates.

410 Gone

Indicates that the requested resource is no longer available and will no longer be available. This should be used when the resource has been intentionally deleted and the resource should be cleared. After receiving the 410 Gone status code, the user should stop requesting resources again.

But most servers will not use this status code, but directly use the 404 Not Found status code.

411 Length Required

The server refuses to accept the request without the Content-Length header defined. After adding a valid Content-Length header indicating the length of the request message body, the client can submit the request again.

412 Precondition Failed

The server failed to meet one or more of the prerequisites given in the request's header fields when validating them. This status code allows the client to set preconditions in the request metainformation (request header field data) when retrieving the resource, thereby preventing the request method from being applied to the resource other than what it expects.

RFC 7232

413 Request Entity Too Large

Indicates that the server refuses to process the current request because the size of the entity data submitted by the request exceeds the range that the server is willing or able to handle. In this case, the server can close the connection to prevent the client from continuing to send this request.

If the situation is temporary, the server should return a Retry-After response header to inform the client how long it can try again.

RFC 7231

414 Request-URI Too Long

Indicates that the requested URI is longer than the server can interpret, so the server refuses to service the request.

Often the result of too much data is encoded as a query string for a GET request, in which case it should be converted to a POST request. Or the form submission that should use the POST method becomes the GET method, causing the query string to be too long.

RFC 7231

415 Unsupported Media Type

The Internet media type submitted in the request is not a format supported by the server for the current request method and the requested resource, so the request is rejected.

For example, the client uploads the image in the format svg, but the server requires the image to be uploaded in the format jpg.

416 Requested Range Not Satisfiable

The client has requested a part of the file, but the server cannot provide it. For example, if the client requires a portion of the file to extend beyond the end of the file.

RFC 7233

417 Expectation Failed

The expected content specified in the request header Expect cannot be satisfied by the server, or the server is a proxy server. This is evidence that the expected content cannot be satisfied on the next node in the current route.

418 I'm a teapot

This opcode was defined in RFC 2324 Hypertext Coffee Pot Control Protocol in 1998 as a traditional IETF April Fools' Day joke and does not need to be defined in a real HTTP server. This error should be returned when an HTCPCP controlling a teapot receives a BREW or POST command asking it to make coffee. This HTTP status code is used as an easter egg in some websites or projects.

RFC 2324

420 Enhance Your Caim

Twitter Search and Trends API return when the client is rate-limited.

421 Misdirected Request

This request is for a server that is unable to produce a response, such as connection reuse.

RFC 7540

422 Unprocessable Entity

The status code extended by the WebDAV (RFC 4918) request means that the request is well-formatted, but cannot be responded to due to semantic errors.

423 Locked

The extended status code requested by WebDAV (RFC 4918) indicates that the current resource is locked.

424 Failed Dependency

The status code extended by WebDAV (RFC 4918) requests indicates that the current request failed due to an error in a previous request, such as PROPPATCH.

425 Unordered Collection

Defined in the WebDAV Advanced Collections Protocol, but does not exist in the Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol.

426 Upgrade Required

Clients SHOULD switch to TLS/1.0 as specified in the HTTP/1.1 Upgrade header.

RFC 2817

428 Precondition Required

The server requires that the request meet certain conditions. This is to prevent the non-update problem, where the client reads the state of a resource, then changes the resource, and writes the resource back to the server, but in the meantime a third party has changed the state of the resource on the server, thus causing a conflict .

RFC 6585

429 Too Many Requests

The user sent too many requests in a given period of time. Intended for network speed limiting.

RFC 6585

431 Request Header Fields Too Large

The server is unwilling to process the request because one or more header fields are too large.

RFC 6585

444 No Response

HTTP server extension on Nginx. The server returns no information to the client and closes the connection (helps block malware).

450 Blocked by Windows Parental Controls

Here is an example of a 450 Blocked by Windows Parental Controls (Microsoft) HTTP status code for informational and testing purposes.

451 Unavailable For Legal Reasons

This access is denied due to legal requirements and was added after approval by the IETF in 2015.

494 Request Header Too Large

Extended HTTP code used on Nginx before error code 431 was raised.

5xx type

This type of status code means that the server cannot complete an obviously valid request. An error or abnormal state occurs while the server is processing the request. It is also possible that the server realizes that it cannot complete the processing of the request with the current software and hardware resources.

Unless this is a HEAD request, the server SHOULD include an explanation of the current error status and whether the condition is temporary or permanent. The browser SHOULD display any entities included in the current response to the user. These status codes apply to any response method.

500 Internal Server Error

Generic error message: The server encountered an unexpected condition that prevented it from completing processing of the request. No specific error message was given.

501 Not Implemented

The server does not support a feature required by the current request. When the server does not recognize the requested method and cannot support its request for any resource. For example, new features of the web service API.

502 Bad Gateway

A server working as a gateway or proxy received an invalid response from an upstream server while trying to perform a request.

503 Service Unavailable

Due to temporary server maintenance or overload, the server is currently unable to process requests. This condition is temporary and will recover after some time. If the delay time can be expected, the response can include a Retry-After header to indicate the delay time. If this Retry-After information is not given, the client SHOULD handle it in the same way as a 500 Internal Server Error response.

504 Gateway Timeout

When a server working as a gateway or proxy attempts to perform a request, it fails to receive a timely response from the upstream server or secondary server.

Note: Some proxy servers will return 400 Bad Request or 500 Internal Server Error when DNS query times out.

505 HTTP Version Not Supported

The server does not support, or refuses to support, the HTTP version used in the request. This implies that the server is unable or unwilling to use the same version as the client. The response should contain an entity describing why the version is not supported and what protocols the server supports.

506 Variant Also Negotiates

Indicates that there is an internal configuration error in the server, and the requested negotiation argument resource is configured to use itself in transparent content negotiation, and therefore is not an appropriate focus in a negotiation process.

RFC 2295

507 Insufficient Storage

A status code extended by the WebDAV (RFC 4918) request that indicates that the server is unable to store the content necessary to complete the request. This condition is considered temporary.

508 Loop Detected

The status code extended by the WebDAV (RFC 5842) request indicates that the server is stuck in an infinite loop when processing the request and can replace the 208 Already Reported status code.

510 Not Extended

The strategies required to acquire resources are not being met.

RFC 2774

511 Network Authentication Required

Clients require authentication to gain network access, designed to restrict access to specific networks to groups of users. For example, a captive portal when connected to a WiFi hotspot.

RFC 6585