Online Tools
Http Status Codes Status Code Meaning
100 The client should continue sending requests. This temporary response is used to inform the client that part of its request has been received by the server and has not been rejected. The client should continue to send the remainder of the request, or ignore this response if the request has been completed. The server must send a final response to the client when the request is complete.
101 The server has understood the client's request and will notify the client via the Upgrade header that a different protocol was used to complete the request. After sending the last blank line of the response, the server will switch to the protocols defined in the Upgrade header. This should only be done if it is advantageous to switch to the new protocol. For example, switching to a new version of HTTP may be advantageous over an older version, or switching to a real-time, synchronous protocol to deliver resources that take advantage of such features.
102 Status codes, extended by WebDAV (RFC 2518), indicate that processing will continue.
200 The request was successful, and the response headers or data body desired by the request will be returned with the response.
201 The request has been fulfilled and a new resource has been created in response to the request, and its URI has been returned with the Location header. If the requested resource cannot be created in time, the following should be returned'202 Accepted'。
202 The server has accepted the request, but 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 nothing more convenient than sending this status code. The purpose of returning a 202 response is to allow the server to accept requests from other processes (such as a batch-based operation that is executed only once a day) without the client having to maintain a connection to the server until the batch operation is fully completed. A response that accepts a request for processing and returns a 202 status code should include in the returned entity some information indicating the current status of the process, as well as a pointer to a processing 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 definitive set valid on the original server, but a copy from a local or third party. The current information may be a subset or superset of the original. For example, metadata containing resources may cause the origin server to know the meta-information super. Use of this status code is not required and is only appropriate if the response would have returned 200 OK without it.
204 The server processed the request successfully, but does not need to return any physical content and wants to return updated meta information. The response may return new or updated meta-information in the form of entity headers. If these headers exist, they should correspond to the requested variables. If the client is a browser, the user's browser SHOULD retain the page on which the request was sent without any changes to the document view, even though the new or updated meta-information should, according to the specification, be applied to the document in the active view of the user's browser. 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 successfully handles the request and returns nothing. However, unlike the 204 response, the response that returns this status code asks 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 prohibited from containing any message body and ends with the first blank line after the message header.
206 The server has successfully processed part of the GET request. HTTP download utilities such as FlashGet or Thunderbolt use this response to perform intermittent downloads or to break up a large file into multiple downloads at the same time. The request must contain a Range header to indicate the range of content the client wishes to receive, and may contain an If-Range as a request condition. The response must contain the following header fields: Content-Range to indicate the scope of the content returned in this response, or, in the case of multipart downloads with a Content-Type of multipart/byteranges, a Content-Range field in each multipart segment to indicate the scope of the content in that segment. If the response contains a Content-Length, its value must match the true number of bytes in the content range it returns. Expires, Cache-Control, and/or Vary, if their values may be different from the values of other previous responses with the same variables. This response should not contain other entity headers if the request uses strong If-Range cache validation, and should not contain other entity headers if the request uses weak If-Range cache validation; this avoids inconsistencies between the cached entity content and the updated entity header information. Otherwise, this response should contain all the entity header fields that should have been returned in the 200 response. If the ETag or Last-Modified headers do not match exactly, the client-side cache should disallow combining the content returned in response 206 with any previously cached content. Any cache that does not support the Range and Content-Range headers is prohibited from caching the content returned by the 206 response.
207 Status codes extended by WebDAV(RFC 2518) The status code, as extended by WebDAV, means that the subsequent message body will be an XML message and may contain a series of separate response codes, depending on the number of previous sub-requests.
300 The requested resource has a series of alternative responses, each with its own specific address and browser-driven negotiation information. It is up to the user or browser to choose a preferred address for redirection. Unless this is a HEAD request, the response should include an entity that is a list of resource characteristics and addresses from which the user or browser can select the most appropriate redirection address. The format of this entity is determined by the format of the Content-Type definition. The browser may automatically make the most appropriate selection based on the format of the response and the browser's own capabilities. Of course, the RFC 2616 specification does not specify how this automatic selection should be done. If the server itself already has a preferred return option, the URI of the return should be specified in the Location; browsers may use this Location value as the address for automatic redirection. In addition, the response is cachable unless otherwise specified.
301 The requested resource has been permanently moved to the new location, and any future references to it should use one of the several URIs returned in this response. If possible, clients with link editing capabilities should automatically change the requested address to the one returned from the server. This response is also cacheable unless otherwise specified. 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 short description. If this is not a GET or HEAD request, the browser is prohibited from automatically redirecting it, unless confirmed by the user, because the terms of the request may have changed 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 next redirection request will be a GET.
302 The requested resource now temporarily responds to the request from a different URI. Since this redirection is temporary, the client should continue to send future requests to the original address. The response is cachable 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 short description. If this is not a GET or HEAD request, then the browser is prohibited from automatically redirecting unless confirmed by the user, as the terms of the request may change as a result. 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 of the original request. Status codes 303 and 307 have been added to clarify what response the server expects from the client.
303 The response to the current request can be found at another URI, and the client should access that resource using GET. This method exists primarily to allow script-activated POST request output to be redirected to a new resource. This new URI is not a replacement reference to the original resource. Also, the 303 response is not allowed to be 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 response entity should contain a hyperlink to the new URI and a short description. Note: Many browsers prior to HTTP/1.1 do not properly understand the 303 state. If interaction with these browsers needs to be considered, the 302 status code should work, since most browsers handle the 302 response in exactly the way that the specification above requires the client to handle the 303 response.
304 This status code should be returned by the server if the client sends a conditional GET request that is allowed and the content of the document has not changed (either since the last visit or according to the conditions of the request). 304 responses are prohibited from containing a message body, and therefore always end with the first blank line after the header of the message. The response must contain the following header information: Date, unless the server does not have a clock. If the server does not have a clock follows these rules, then the proxy server and the client can add the Date field to the incoming response header themselves (as specified in RFC 2068), and the caching mechanism will work properly. Expires, Cache-Control, and/or Vary, if their values may be different from the values of other previous responses with the same variables. If the response request uses strong cache validation, then the response should not contain additional entity headers; otherwise (e.g., a conditional GET request uses weak cache validation), the response is prohibited from containing additional 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 repeat the request without the restriction. If a 304 response is received requesting that a cache entry be updated, 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 a specified proxy. The Location field will give information about the URI of the specified proxy, and the recipient will need to send a separate request repeatedly to access the resource through this proxy. Only the original server can create a 305 response. Note: It is not clear from RFC 2068 that a 305 response is intended to redirect a single request and can only be created by the originating 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 Requested resources now temporarily respond to requests from different URIs. Since this redirection is temporary, clients 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 response entity should contain a hyperlink to the new URI and a short description. Since some browsers do not recognize the 307 response, it is necessary to add the above information 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 the user's confirmation, because the conditions of the request may change.
400 1, semantic error, the current request can not be understood by the server. Unless modified, the client should not repeat the request. 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 for user information. The client may resubmit a request with the appropriate Authorization header information. If the current request already contains Authorization credentials, then a 401 response means that the server verifies that those credentials have been rejected. If the 401 response contains the same authentication query as the previous response, and the browser has already made at least one attempt at authentication, 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 refuses to honor it. Unlike a 401 response, authentication does not provide any help, and the request should not be resubmitted. If this is not a HEAD request, and the server wants to be able to say why the request cannot be executed, then the reason for refusal should be described in the entity. Of course, the server can also return a 404 response if it does not want the client to get any information.
404 The request failed, the requested resource was not found on the server. There is no information to tell the user whether the situation is temporary or permanent. If the server is aware of the situation, it should use the 410 status code to inform the server that the old resource is permanently unavailable due to some internal configuration mechanism and that there is no redirection available. 404 is widely used when the server doesn't want to reveal why the request was rejected or when 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 the list of request methods that are acceptable for the current resource. Since the PUT and DELETE methods write to the resource on the server, most web servers do not support them or do not allow them by default, and will return a 405 error for such requests.
406 The content characteristics of the requested resource do not satisfy the conditions in the request header and a response entity cannot be generated. Unless this is a HEAD request, the response should return an entity containing a list of addresses from which the user or browser can select the most appropriate entity characteristics. 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 choices.
407 Similar to the 401 response, except that the client must authenticate with the proxy server. The proxy server MUST return a Proxy-Authenticate for identity interrogation. The client may return a Proxy-Authorization header for authentication. See RFC 2617.
408 Request timeout. The client did not complete sending a request within the time the server was prepared to wait. The client may resubmit the request at any time without making any changes.
409 The request could not be completed due to a conflict with the current state of the requested resource. This code is only allowed to be used if the user is considered to be able to resolve the conflict and resubmit a new request. The response should contain enough information for the user to discover the source of the conflict. Conflicts often occur in the processing of PUT requests. For example, in a version-checking environment, a PUT submitted to modify a particular resource with version information that conflicts with a previous (third-party) request should return a 409 error informing the user that the request could not be completed. In this case, the response entity is likely to contain a comparison of the 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 there is no known forwarding address. Such a situation should be considered permanent. If possible, clients 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 the 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 assist the webmaster in maintaining the site by informing the user that the resource is no longer available and that the server owner wishes all remote connections to the resource to be deleted as well. This type of event is common in time-limited, value-added services. Similarly, the 410 response is used to notify the client that a resource belonging to an individual is no longer available at the current server site. Of course, the question of whether all permanently unavailable resources need to be labeled as such, and how long they need to be kept that way, is also important.'410 Gone'， and how long it should be maintained is entirely up to the server owner.
411 The server refuses to accept requests without the Content-Length header defined. The client may resubmit the request after adding a valid Content-Length header indicating the length of the request message body.
412 The server failed to fulfill one or more of the prerequisites given in the request's header field when verifying the request. This status code allows the client to set preconditions in the request's meta-information (request header field data) when obtaining a resource, thus preventing the request method from being applied to resources other than the content it desires.
413 The server refuses to process the current request because it submits more physical data than the server is willing or able to handle. In this case, the server may close the connection to prevent the client from continuing to send the request. If the situation is temporary, the server should return a Retry-After header to inform the client of the amount of time after which it can try again.
414 The request URI is longer than the server can interpret, so the server refuses to serve the request. This is rare, and is often the case when a form submission that should have used the POST method becomes a GET method, resulting in a long query string. Redirect URI "black holes", such as using the old URI as part of the new URI for each redirect, resulting in a long URI after several redirects. Clients are attempting to attack servers by exploiting security vulnerabilities that exist in some servers. Such servers use a fixed-length buffer to read or manipulate the requested URI, which may result in a buffer overflow when the GET parameter exceeds a certain value, leading to arbitrary code execution.[1]。 Servers without such vulnerabilities should return a 414 status code.
415 For the currently requested method and requested resource, the entity submitted in the request is not in a format supported by the server and the request is rejected.
416 If the request contains a Range request header, and any data ranges specified in the Range do not coincide with the ranges available for the current resource, and the request does not define an If-Range request header, then the server should return a 416 status code. If Range uses byte ranges, then this means that the first byte 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 that specifies the length of the current resource along with the 416 status code. This response is also prohibited from using multipart/byteranges as its Content-Type.
417 The expected content specified in the request Expect header cannot be met by the server, or the server is a proxy server that has clear evidence that the content of the Expect cannot be met at the next node in the current route.
421 The number of connections to the server from the IP address of the current client exceeds the maximum allowed by the server. Typically, the IP address here refers to the client's address as seen from the server (e.g., the user's gateway or proxy server address). In this case, more than one end-user may be involved in the connection count.
422 The number of connections from the current client's IP address to the server exceeds the maximum allowed by the server. Typically, the IP address here refers to the client's address as seen from the server (e.g., the user's gateway or proxy server address). In this case, more than one end-user may be involved in the connection count.
422 The request was formatted correctly, but could not be responded to because it contained semantic errors. (RFC 4918 WebDAV) 423 Locked The current resource is locked. (RFC 4918 WebDAV) 423 Locked
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 does not appear in the WebDAV Sequential Collections Protocol (RFC 3658).
426 Clients should switch to TLS/1.0. (RFC 2817)
449 Extended by Microsoft to represent that requests should be retried after the appropriate action has been performed.
500 The server encountered an unforeseen condition that prevented it from completing processing of the request. Typically, this problem occurs when the server has a program code error.
501 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.
502 A server working as a gateway or proxy receives an invalid response from an upstream server when it tries to execute a request.
503 The server is currently unable to process the request due to temporary server maintenance or overload. This condition is temporary and will be restored after a period of time. If a delay can be expected, the response can include a Retry-After header to indicate the delay. If this Retry-After information is not given, then the client should handle it in the same way as a 500 response. Note: The existence of the 503 status code does not mean that the server must use it if it is overloaded. Some servers simply want to deny the client a connection.
504 A server acting as a gateway or proxy that attempts to perform a request does not receive a timely response from an upstream server (a server identified by a URI, such as HTTP, FTP, LDAP) or a secondary server (such as DNS). Note: Some proxy servers return a 400 or 500 error when the DNS lookup 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 is unable or unwilling to use the same version as the client. The response should contain an entity that describes why the version is not supported and what protocols the server supports.
506 Extended by the Transparent Content Negotiation Protocol (RFC 2295) to represent an internal misconfiguration on the part of the server: the requested Negotiation Variant resource is configured to use itself in Transparent Content Negotiation, and is therefore not an appropriate focus in a negotiation process.
507 The server is unable to store the content necessary to fulfill the request. This condition is considered temporary.WebDAV(RFC 4918)
509 The server reached its bandwidth limit. This is not an official status code, but is still widely used.
510 The policy required to obtain the resource has not been satisfied. (RFC 2774)
Access to records: