HTTP Status Code table

HTTP status code in detail-query data

1XX message

This type of status code, on behalf of which the request has been accepted, needs to be processed. This type of response is a temporary response that contains only the status line and some optional response header information and ends with a blank line. Because no 1XX status codes are defined in the HTTP/1.0 protocol, the server prohibits sending a 1xx response to such clients unless under some experimental conditions. These status codes represent a response that is informational and identifies other actions that the customer should take.

Continue

The server has received the request header, and the client should continue to send the request principal (in the case of a request to send the body: For example, a POST request), or ignore the response if the request has been completed. The server must send a final response to the client after the request is complete. For the server to check the requested header, the client must send Expect:100-continue as the header in its initial request and receive the continue status code before the body is sent. Response Code 417 Hope failure indicates that the request should not continue.

101 Switching protocols

The server has understood the client's request and will notify the client via a upgrade message header that a different protocol is being used to complete the request. After the last empty line of the response is sent, the server switches to those protocols defined in the upgrade message header.

Similar measures should be taken only when switching to a new protocol is more beneficial. For example, switching to a new HTTP version (such as HTTP/2) is more advantageous than an older version, or switching to a real-time, synchronized protocol such as WebSocket to deliver resources that exploit such features.

102 Processing

WebDAV requests may contain many child requests involving file operations that take a long time to complete the request. The code indicates that the server has received and is processing the request, but no response is available. This prevents the client from timing out and assumes that the request is missing.

2XX success

This type of status code indicates that the request has been successfully received, understood, and accepted by the server.

OK

The request was successful, and the desired response header or data body will be returned with this response. The actual response will depend on the request method being used. In a GET request, the response contains the entity that corresponds to the requested resource. In a POST request, the response will contain the entity describing or manipulating the result.

201 Created

The request has been implemented and a new resource has been created according to the request, and its URI has been returned with the location header information. If the required resources cannot be created in time, the ' 202 Accepted ' should be returned.

202 Accepted

The server has accepted the request but has not yet processed it. Eventually the request may or may not be executed, and may be blocked when processing occurs.

203 non-authoritative information (since http/1.1)

The server is a conversion proxy (transforming proxy, for example, a network accelerator), which originates from a $ OK status code, but responds to a modified version of the original response.

204 No Content

The server successfully processed the request and did not return any content.

205 Reset Content

The server successfully processed the request, but did not return any content. Unlike the 204 response, this response requires the requestor to reset the document view.

206 Partial Content

The server has successfully processed a partial GET request. HTTP download tools such as FlashGet or Thunderbolt are used to implement a breakpoint continuation or to decompose a large document into multiple download segments for download at the same time.

207 Multi-Status

The message body after the representation will be an XML message and may contain a series of independent response codes, depending on the number of previous child requests.

208 already reported

The members of the DAV binding have been enumerated before (a multi-state) response, and are not included again.

226 IM used

The server has satisfied the request for the resource, representing the result of one or more entity operations requested by the entity.

3xx redirection

This type of status code represents the need for the client to take further action to complete the request. Typically, these status codes are used for redirection, and subsequent request addresses (redirected targets) are indicated in the location domain of the response.

The user's browser can automatically submit required subsequent requests without user intervention, when and only if the method used by subsequent requests is get or head. The client should automatically monitor for Infinite loop redirection (ex: a→b→c→ ...). →a or A→a), because this causes a large amount of unnecessary resource consumption for the server and the client. The browser should not automatically access more than 5 redirects, as recommended by the Http/1.0 Edition specification.

Multiple Choices

The requested resource has a range of available feedback information, each with its own specific address and browser-driven negotiation information. The user or browser is able to choose a preferred address to redirect itself.

Unless this is a head request, the response should include an entity with a list of resource attributes and addresses so that 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 ability of the browser itself. Of course, the RFC 2616 specification does not specify how such an automatic selection should proceed.

If the server itself already has the preferred feedback option, the URI of the feedback should be indicated in the location, which the browser may use as the address for automatic redirection. In addition, 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 by this response. If possible, clients that have link editing capabilities should automatically modify the requested address to the address returned from the server. Unless otherwise specified, the response is cacheable.

The new permanent URI should be returned in the location domain of the response. Unless this is a head request, the response entity should contain a hyperlink to the new URI and a short description.

If this is not a get or head request, the browser disables automatic redirection unless the user confirms it, because the requested condition may vary.

Note: For some browsers that use the http/1.0 protocol, when they send a POST request that gets a 301 response, the next redirect request becomes a Get method.

302 Found

Requires the client to perform a temporary redirect (the original description phrase is "Moved temporarily"). Because such redirects are 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 location domain of the response. Unless this is a head request, the response entity should contain a hyperlink to the new URI and a short description.

If this is not a get or head request, then the browser disables automatic redirection unless the user confirms it, because the requested condition may vary.

Note: Although the RFC 1945 and RFC 2068 specifications do not allow the client to change the method of the request during redirection, many existing browsers treat the 302 response as a 303 response, and use get to access the URI specified in the location, ignoring the method originally requested. So status Codes 303 and 307 are added to clarify how the server expects the client to react.

303 See other

The response to the current request can be found on another URI, and when the response is received by post (or Put/delete), the client should assume that the server has received the data and should use a separate get message to issue the redirect. This method exists primarily to allow the output of the POST request that is activated by the script to redirect to a new resource. This new URI is not an alternative reference to the original resource. Meanwhile, a 303 response is forbidden to be cached. Of course, a second request (redirect) may be cached.

The new URI should be returned in the location domain of the response. Unless this is a head request, the response entity should contain a hyperlink to the new URI and a short description.

Note: Many http/1.1 versions of previous browsers do not correctly understand the 303 status. If you need to consider the interaction with these browsers, the 302 status code should be competent, because most browsers handle 302 response in the way that the above specification requires the client to handle the 303 response should be done.

304 Not Modified

Indicates that the resource was not modified because the request header specifies the version if-modified-since or If-none-match. In this case, the client does not need to retransmit the resource because it still has a previously downloaded copy.

305 Use Proxy

The requested resource must be accessed through the specified proxy. The URI information for the specified proxy is given in the location domain, and the recipient needs to send a separate request repeatedly to access the resource. Only the original server can create a 305 response. Many HTTP clients, such as Mozilla and Internet Explorer, have not handled the response to this status code correctly, primarily for security reasons.

Note: There is no explicit 305 response in RFC 2068 to redirect a single request and can only be established by the original server. Ignoring these restrictions can lead to serious security consequences.

306 Switch Proxy

In the latest version of the specification, the 306 status code is no longer in use. The initial point is that "subsequent requests should use the specified proxy."

307 Temporary Redirect

In this case, the request should be duplicated with another URI, but the subsequent request should still use the original URI. In contrast to 302, the change request method is not allowed when the original request is re-issued. For example, you should use another POST request to repeat the POST request.

308 Permanent Redirect

The request and all future requests should be duplicated using another URI. 307 and 308 Repeat the behavior of 302 and 301, but do not allow HTTP method changes. For example, a resource that submits a form to a permanent redirect might go smoothly.

4XX Client Error

This type of status code indicates that the client may appear to have an error that prevents the server from processing. Unless the response is a head request, the server should return an entity that interprets the current error condition, and whether this is a temporary or permanent condition. These status codes apply to any request method. The browser should display to the user any entity content contained in such an error response.

If the client is transmitting data when an error occurs, the server implementation using TCP should carefully ensure that the client has received a packet containing the error message before shutting down 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 sends a reset packet to the client to clear all unrecognized input buffers for that client so that the data is not read by the application on the server and interferes with the latter.

Request

Because of a noticeable client error (for example, malformed request syntax, too large size, invalid request message, or spoofed routing request), the server cannot or does not process the request.

401 Unauthorized

Similar to 403 forbidden,401 semantics is "unauthenticated", that is, the user does not have the necessary credentials. The status code indicates that the current request requires user authentication. The response must contain a Www-authenticate information header for the requested resource to ask for user information. The client can repeatedly submit a request that contains the appropriate authorization header information. If the current request already contains the authorization certificate, the 401 response indicates that the certificate has been rejected by the server authentication. If the 401 response contains the same authentication query as the previous response, and the browser has tried at least one validation, the browser should show the user the entity information contained in the response, because the entity information may contain related diagnostic information.

Note: When a website (usually a website domain name) prohibits an IP address, some site status codes display 401, indicating that the particular address is denied access to the site.

402 Payment Required

This status code is reserved for possible future requirements. The initial intent of the status code may be used as part of some form of digital cash or online payment scheme, but few service providers are used, and this status code is usually not used. The Google developers API uses this status code if a specific developer has exceeded the requested daily limit.

403 Forbidden

The server has understood the request, but refuses to execute it. Unlike the 401 response, authentication does not provide any 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 to get any information.

404 Not Found

The request failed, and the requested resource was not found on the server, but the user's subsequent request was allowed. No information can tell the user whether the situation is temporary or permanent. If the server knows the situation, it should use the 410 status code to tell the old resources because of some internal configuration mechanism problems, has been permanently unavailable, and there is no jump to the address. 404 This status code is widely used when the server does not want to reveal exactly why the request was rejected or if no other appropriate response is available. ‘

405 Method not allowed

The request method specified in the request line cannot be used to request the appropriate resource. The response must return an allow header to indicate a list of request methods that the current resource can accept. For example, a GET request on a form that needs to render data through post, or a put request on a read-only resource.

Because the Put,delete method writes to resources on the server, most Web servers do not support or do not allow the above request method under the default configuration, and 405 errors are returned for such requests.

406 Not acceptable

The content attribute of the requested resource could not satisfy the condition in the request header, so the response entity could not be generated and the request was unacceptable. Unless this is a head request, the response should return an entity that contains the most appropriate entity attributes and address lists that the user or browser can choose 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 its format and ability. However, the specification does not define any criteria for making such automatic selections.

407 Proxy Authentication Required

Similar to the 401 response, except that the client must authenticate on the proxy server. The proxy server must return a proxy-authenticate to be used for identity questioning. The client can return a Proxy-authorization message header for verification.

408 Request Timeout

The request timed out. According to the HTTP specification, the client does not complete a request to be sent within the time the server prepares to wait, and the client can submit the request again at any time without making any changes.

409 Conflict

Represents an edit conflict that cannot be processed because of a request conflict, such as multiple synchronization 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 is intentionally deleted and the resource should be purged. After receiving the 410 status code, the user should stop requesting the resource again. However, most services do not use this status code, but instead use the 404 status code directly.

411 Length Required

The server refuses to accept the request without defining a content-length header. After adding a valid Content-length header that indicates the body length of the request message, the client can submit the request again.

412 Precondition Failed

The server failed to satisfy one or more of these when validating the prerequisites in the header field of the request. This status code allows the client to set the prerequisites in the requested meta-information (Request header field data) when acquiring the resource, to prevent the request method from being applied to resources other than what it wants.

413 Request Entity Too Large

The previously called "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 scope 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 this condition is temporary, the server should return a retry-after response header to tell the client how much time it can retry.

414 Request-uri Too Long

The previously called "Request-uri Too Long" indicates that the requested URI is longer than the server can interpret, so the server refuses to service the request. The result of too much data is typically encoded as a query string for a GET request, in which case it should be converted to a POST request. This is rare, and the usual situations include:

• A form submission that should use the Post method becomes a Get method, which causes the query string to be too long.

• REDIRECT uri "Black Hole", for example, each redirect takes the old Uri as part of the new URI, resulting in a long URI after several redirects.

• The client is trying to exploit a security vulnerability in some servers to attack the server. This type of server uses a fixed-length buffer to read or manipulate the requested URI, and when the get parameter exceeds a certain value, a buffer overflow may result, resulting in arbitrary code being executed. A server that does not have such a vulnerability should return a 414 status code.

415 Unsupported Media Type

For the currently requested method and the requested resource, the Internet media type submitted in the request is not a supported format in the server, so the request is rejected. For example, the client uploads the image to SVG, but the server requires that the image be jpg in the upload format.

416 Requested Range not satisfiable

Formerly known as "requested Range not satisfiable". The client has requested a portion of the file (Byte serving), but the server cannot provide that part. For example, if the client requires a portion of the file to exceed the end of the file.

417 Expectation Failed

The expected content specified in the request header expect could not be satisfied by the server, or the server was a proxy for evidence that the contents of expect could not be satisfied on the next node of the current route.

418 I ' m a teapot

This opcode was defined in the 1998 as an IETF traditional April Fool's joke, in the RfC 2324 Hypertext Coffee Pot Control Protocol, and does not need to be defined in a real HTTP server. This error should be returned when a HTCPCP of a control teapot receives a brew or post instruction requiring its coffee to be brewed. This HTTP status code is on some websites (including google.com) with projects such as node. js, ASP. NET and go languages) as eggs.

420 Enhance Your Caim

The Twitter search and trends API are returned with a limited speed for the client.

421 misdirected Request

The request is for a server that cannot generate a response (for example, because of connection reuse).

422 Unprocessable Entity

The request is well-formed, but cannot be responded to because of a semantic error.

423 Locked

The current resource is locked.

424 Failed Dependency

The current request failed, such as Proppatch, because of an error that occurred in a previous request.

425 Unordered Collection

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

426 Upgrade Required

The client should switch to tls/1.0 and be given in the http/1.1 Upgrade header.

428 Precondition Required

The original server requires that the request meet certain conditions. This is to prevent the ' not updated ' problem, which is that the client reads (GET) The state of a resource, changes it, and writes it back to the server, but during this time the third party has changed the state of the resource on the server and therefore caused the conflict. ”

429 Too Many requests

The user has sent too many requests within a given time. Designed for network speed limit.

431 Request Header Fields Too Large

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

444 No Response

Nginx on the HTTP server extension. The server does not return any information to the client and closes the connection (to help prevent malicious software).

Blocked by Windows parental Controls

This is an example of a 450 status code that is blocked by Windows Home Control (Microsoft) HTTP for information and testing.

451 Unavailable for Legal reasons

The visit was rejected as a result of legal requirements and was increased by the IETF after 2015 approval.

494 Request Header Too Large

The extension HTTP code used on Nginx before error code 431 is presented.

5XX Server Error

Indicates that the server was unable to complete a clearly valid request. This type of status code indicates that the server has an error or an abnormal state in the process of processing the request, or that the server is aware that the processing of the request cannot be completed with the current hardware and software resources. Unless this is a head request, the server should contain an explanatory information entity that interprets the current error state and whether the condition is temporary or permanent. The browser should show the user any entities that are contained in the current response. These status codes apply to any response method.

Internal Server Error

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

501 Not implemented

The server does not support a feature that is required for 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 network Services API)

502 Bad Gateway

An invalid response was received from the upstream server when the server acting as a gateway or agent attempted to execute the request.

503 Service Unavailable

The server is currently unable to process the request due to temporary server maintenance or overloading. This situation is temporary and will be resumed after a certain period of time. If the delay time can be estimated, then the response can include a retry-after header to indicate the delay time. If this retry-after message is not given, the client should handle it in a manner that handles 500 responses.

504 Gateway Timeout

When a server acting as a gateway or agent attempts to execute a request, it fails to receive a response from the upstream server (the server that the URI identifies, such as HTTP, FTP, LDAP), or the secondary server (such as DNS).

Note: Some proxy servers return 400 or 500 errors during DNS query timeout.

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 cannot or does not want to use the same version as the client. The response should contain an entity that describes why the version is not supported and which protocols the server supports.

506 Variant Also negotiates

Extended by the Transparent Content negotiation Protocol (RFC 2295), there is an internal configuration error on behalf of the server, and the requested negotiation meta-resource is configured to use itself in transparent content negotiation, so it is not an appropriate focus in a negotiation process.

507 Insufficient Storage

The server cannot store the content necessary to complete the request. The situation is considered to be temporary.

508 Loop Detected

The server was caught in a dead loop while processing the request.

510 Not Extended

The policies needed to get the resources are not met.

511 Network Authentication Required

Clients require authentication to gain network access and are designed to restrict the user base from accessing a specific network. (such as a forced network portal when connecting to a WiFi hotspot)

HTTP Status Code table