Http status codeStatus code meaning
100The client should continue sending requests. This provisional 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 sending the remainder of the request, or ignore this response if the request has already completed. The server MUST send a final response to the client after the request is complete.
101The server has understood the client's request and will notify the client through the Upgrade header to use a different protocol to complete the request. After sending the blank line at the end of this response, the server will switch to those protocols defined in the Upgrade header. Similar measures should only be taken when it is more beneficial to switch to a new protocol. For example, switching to a new HTTP version has advantages over older versions, or switching to a real-time and synchronous protocol for delivering resources that take advantage of such features.
102A status code extended by WebDAV (RFC 2518) indicating that processing will continue.
200The request has succeeded, and the response headers or data bodies expected by the request will be returned with this response.
201The request has been fulfilled, and a new resource has been created according to the request, and its URI has been returned with the Location header . If the required resources cannot be created in time, '202 Accepted' should be returned.
202The server has accepted the request but has not yet processed it. Just as it may be rejected, eventually the request may or may not be executed. In the case of asynchronous operations, there is nothing more convenient than sending this status code. The purpose of returning a response with a 202 status code is to allow the server to accept requests from other processes (such as a batch-based operation that only executes once a day) without having to keep the client connected to the server until the batch operation is complete. A response that accepts a request for processing and returns a 202 status code should include some information in the returned entity indicating the current status of the processing, as well as a pointer to a processing status monitor or state prediction, so that the user can estimate whether the operation has completed.
203The server has successfully processed the request, but the returned entity header meta information is not a valid set of Local or third-party copies. The current information may be a subset or superset of the original version. For example, metadata containing a resource may cause the origin server to know the super of the metadata. The use of this status code is not required and is only appropriate if the response would return 200 OK without this status code.
204The server successfully processed the request, but did not need to return any entity content and wanted to return updated meta information. The response may return new or updated meta information in the form of entity headers. These headers, if present, should correspond to the requested variables. If the client is a browser, then the user's browser SHOULD retain the page that sent the request without any change in the document view, even if new or updated meta information should be applied to the user's browser activity per specification document in view. Since a 204 response is forbidden to contain any body, it always ends with the first blank line after the header.
205The server successfully processed the request and returned nothing. But unlike a 204 response, a response that returns this status code requires the requester to reset the document view. This response is mainly used to reset the form immediately after accepting user input so that the user can easily start another input. Like the 204 response, this response is also MUST NOT contain any body and ends with the first blank line after the header.
206The server has successfully processed part of the GET request. HTTP download tools like FlashGet or Xunlei use this type of response to resume the upload from a breakpoint or to break down a large document into multiple download segments for simultaneous download. The request MUST contain the Range header to indicate the range of content the client expects, and may contain If-Range as a request condition. The response must contain the following header fields: Content-Range is used to indicate the range of content returned in this response; if it is a multipart download with Content-Type of multipart/byteranges, each multipart segment should contain Content-Range The domain is used to indicate the scope of the content of this paragraph. If Content-Length is included in the response, its value must match the actual number of bytes in the content range it returns. Date ETag and/or Content-Location, if the same request should have returned a 200 response. Expires, Cache-Control, and/or Vary, if the value may be different from the value corresponding to other responses of the same variable before. If this response request uses If-Range strong cache verification, then this response should not contain other entity headers; if this response request uses If-Range weak cache verification, this response is prohibited from containing other entity headers; this avoids The inconsistency between the cached entity content and the updated entity header information has been resolved. Otherwise, this response SHOULD contain all entity header fields that should have been returned in a 200 response. If the ETag or Last-Modified headers do not match exactly, client caches SHOULD NOT combine the content returned in a 206 response with any previously cached content. Any cache that does not support Range and the Content-Range header MUST NOT cache the content returned by a 206 response.
207A status code extended by WebDAV (RFC 2518), indicating that the following message body will be an XML message, and may follow the previous subrequest The number varies and contains a series of independent response codes.
300The requested resource has a range of optional feedback messages, each with its own specific address and browser-driven negotiation message . 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 properties and addresses from which the user or browser can choose the most appropriate redirection 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 capabilities of the browser itself. 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 option, then the URI of the feedback should be specified in the Location; the browser may use the Location value as the address for automatic redirection. Also, unless otherwise specified, this response is also cacheable.
301The requested resource has been permanently moved to a new location, and any future references to this resource should use the number of values ​​returned in this response One of the URIs. 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 entity of the response SHOULD contain a hyperlink to the new URI and a short description. If this is not a GET or HEAD request, the browser therefore prohibits automatic redirection unless confirmed by the user, as the conditions of the request may change accordingly. Note: For some browsers using the HTTP/1.0 protocol, when they send a POST request and get a 301 response, the subsequent redirect request will become a GET method.
302The requested resource is now temporarily responding to the request from a different URI. Since 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 entity of the response SHOULD contain a hyperlink to the new URI and a short description. If this is not a GET or HEAD request, the browser prohibits automatic redirection unless confirmed by the user, as the conditions of the request may change accordingly. Note: Although the RFC 1945 and RFC 2068 specifications do not allow the client to change the method of the request when redirecting, many existing browsers treat the 302 response as a 303 response and use GET to access the URI specified in the Location without ignoring The method originally requested. Status codes 303 and 307 were added to clarify what response the server expects from the client.
303The response to the current request can be found at another URI, and the client SHOULD use GET to access that resource. This method exists primarily to allow script-activated POST request output to be redirected to a new resource. This new URI is not an alternate reference to the original resource. Also, 303 responses MUST NOT be cached. Of course, the second request (redirect) may be cached. The new URI should be returned in the Location field of the response. Unless this is a HEAD request, the entity of the response SHOULD contain a hyperlink to the new URI and a short description. Note: Many pre-HTTP/1.1 browsers do not properly understand the 303 status. If interaction with these browsers is a concern, the 302 status code should do the trick, since most browsers handle 302 responses exactly the way the above specification requires clients to handle 303 responses.
304The server SHOULD return this status code if the client sent a conditional GET request and the request was allowed, but the content of the document (since the last access or according to the conditions of the request) has not changed. A 304 response MUST NOT contain a message body, so it always ends with the first blank line after the header. The response MUST contain the following headers: Date, unless the server does not have a clock. If servers without a clock follow these rules, then proxies and clients can add the Date field to the received response header (as specified in RFC 2068) and the caching mechanism will work. ETag and/or Content-Location, if the same request would have returned a 200 response. Expires, Cache-Control, and/or Vary, if the value may be different from the value corresponding to other responses of the same variable before. If this response request uses strong cache validation, then this response should not contain other entity headers; otherwise (for example, a conditional GET request uses weak cache validation), this response MUST NOT contain other entity headers; this avoids Inconsistencies between cached entity content and updated entity header information were resolved. If a 304 response indicates that an entity is currently not cached, the caching system MUST ignore the response and repeat the request without the restriction. If a 304 response is received asking to update a cache entry, the cache system must update the entire entry to reflect the values ​​of all fields that were updated in the response.
305The requested resource must be accessed through the specified proxy. The URI information of the specified proxy will be given in the Location field. The receiver needs to repeatedly send a separate request to access the corresponding resource through this proxy. Only the origin server can build a 305 response. Note: RFC 2068 does not specify that a 305 response is intended to redirect a single request and can only be established by the origin server. Ignoring these restrictions can have serious security consequences.
306In the latest version of the specification, the 306 status code is no longer used.
307The requested resource is now temporarily responding to the request from a different URI. Since 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 entity of the response SHOULD contain a hyperlink to the new URI and a short description. Because some browsers do not recognize the 307 response, it is necessary to add the above necessary information so that the user can understand and make an access request to the new URI. If this is not a GET or HEAD request, the browser prohibits automatic redirection unless confirmed by the user, as the conditions of the request may change accordingly.
4001. The semantics are incorrect, and the current request cannot be understood by the server. The client SHOULD NOT submit this request repeatedly unless modified. 2. The request parameters are incorrect.
401The current request requires user authentication. The response MUST contain a WWW-Authenticate header appropriate for the requested resource to ask the user for information. The client MAY repeatedly submit a request with the appropriate Authorization headers. If the current request already contains Authorization certificates, the 401 response means that the server has rejected those certificates for verification. If the 401 response contains the same authentication challenge as the previous response, and the browser has attempted at least one authentication, the browser SHOULD present the user with the entity information contained in the response, which may contain relevant diagnostic information . See RFC 2617.
402This status code is reserved for possible future needs.
403The server understood the request, but refused to execute it. Unlike a 401 response, authentication doesn't help, and the request shouldn't be resubmitted. If this is not a HEAD request, and the server wishes to be able to articulate why the request could not be performed, then the reason for the rejection should be described in the entity. Of course the server can also return a 404 response if it doesn't want the client to get any information.
404The request failed, the requested resource was not found on the server. There is no information to tell the user whether the condition is temporary or permanent. If the server knows about the situation, it should use the 410 status code to inform that the old resource is permanently unavailable due to some internal configuration mechanism problem, and there is no address to jump to. The 404 status code is widely used when the server does not want to reveal exactly why the request was rejected or when no other suitable response is available.
405The 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 the current resource can accept. In view of the PUT and DELETE methods that will write to the resources on the server, most web servers do not support or do not allow the above request methods under the default configuration, and 405 errors will be returned for such requests.
406The content property of the requested resource cannot meet the conditions in the request header, so 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 select the most appropriate entity. The format of the entity is determined by the media type defined in the Content-Type header. The browser can make the best choice on its own based on the format and its own capabilities. However, the specification does not define any criteria for making such automatic selections.
407Similar to a 401 response, except that the client must authenticate on the proxy server. The proxy server MUST return a Proxy-Authenticate for identity queries. The client MAY return a Proxy-Authorization header for authentication. See RFC 2617.
408The request timed out. The client did not complete a request within the time the server was prepared to wait. The client can submit this request again at any time without making any changes.
409The 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 able to resolve the conflict and will resubmit a new request. The response should contain enough information for the user to discover the source of the conflict. Conflicts usually occur in the processing of PUT requests. For example, in an environment where version checking is used, the version information attached to a modification request for a specific resource submitted by a PUT conflicts with a previous (third-party) request, then the server should return a 409 error at this time. Inform the user that the request could not be completed. At this point, the response entity will likely contain a diff comparison between the two conflicting versions, so that the user can resubmit the new version after the merge.
410The requested resource is no longer available on the server and does not have any known forwarding address. Such a condition 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 the 404 status code should be used. Unless otherwise specified, this response is cacheable. The purpose of the 410 response is mainly to help webmasters maintain the web site, inform users that the resource is no longer available, and that the server owner wants all remote connections to this resource to be deleted as well. Such events are common in limited-time, value-added services. Likewise, the 410 response is used to inform the client that resources originally belonging to an individual are no longer available on the current server site. Of course, it is entirely up to the server owner to mark all permanently unavailable resources as '410 Gone', and for how long.
411Server refused if Conten is not definedt-LengthThe request is accepted without the header. After adding a valid Content-Length header indicating the length of the request message body, the client MAY submit the request again.
412The server failed to satisfy one or more of the prerequisites given in the request's header field while validating. This status code allows the client to set prerequisites in the request's meta-information (request header field data) when retrieving the resource, thereby preventing the request method from being applied to resources other than what it expects.
413The server refused to process the current request because the request submitted entity data larger 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 this request. If the condition is temporary, the server SHOULD return a Retry-After response header to tell the client how much time later to retry.
414The requested URI is longer than the server can interpret, so the server refused to serve the request. This is relatively rare, and the usual cases include: the form submission that should have used the POST method has become the GET method, resulting in an excessively long Query String. Redirect URI "black hole", for example, each redirect uses the old URI as part of the new URI, resulting in an excessively long URI after several redirects. The client is trying to attack the server by exploiting a security hole that exists in some server. This type of server uses a fixed-length buffer to read or manipulate the requested URI. When the parameters after GET exceed a certain value, a buffer overflow may occur, resulting in arbitrary code execution [1]. Servers without such vulnerabilities should return a 414 status code.
415For the currently requested method and requested resource, the entity submitted in the request is not in a format supported by the server, so the request is reject.
416If the Range request header is included in the request, and any data range specified in Range does not coincide with the available range of the current resource, and If the If-Range request header is not defined in the request, the server should return a 416 status code. If Range uses a byte range, then this situation means that the first byte position of all data ranges specified by the request exceeds the length of the current resource. The server should also include a Content-Range entity header to indicate the length of the current resource when returning the 416 status code. This response is also prohibited from using multipart/byteranges as its Content-Type.
417The expected content specified in the request header Expect cannot be satisfied by the server, or the server is a proxy server, and it has clear evidence that The content of Expect could not be satisfied on the next node of the current route.
421The number of connections to the server from the current client's IP address exceeds the maximum allowed range for the server. Usually, the IP address here refers to the client address (such as the user's gateway or proxy server address) as seen from the server. In this case, the calculation of the number of connections may involve more than one end user.
422The number of connections to the server from the current client's IP address exceeds the maximum allowed by the server. Usually, the IP address here refers to the client address (such as the user's gateway or proxy server address) as seen from the server. In this case, the calculation of the number of connections may involve more than one end user.
422The request is well-formed, but cannot be responded to due to a semantic error. (RFC 4918 WebDAV) 423 Locked The current resource is locked. (RFC 4918 WebDAV)
424The current request failed due to an error in a previous request, such as PROPPATCH. (RFC 4918 WebDAV)
425 is defined in the WebDav Advanced Collections draft, but does not appear in the WebDAV Sequenced Collections Protocol (RFC 3658) .
426Clients should switch to TLS/1.0. (RFC 2817)
449Extended by Microsoft to indicate that the request should be retried after taking the appropriate action.
500The server encountered an unexpected condition that prevented it from completing the request. Typically, this problem occurs when the server's program code is wrong.
501A feature required by the current request is not supported by the server. When the server does not recognize the requested method and cannot support its request for any resource.
502A server working as a gateway or proxy received an invalid response from the upstream server when attempting to execute the request.
503The server is currently unable to process the request due to temporary server maintenance or overload. This condition is temporary and will return after a period of time. If the delay time can be expected, the response MAY include a Retry-After header to indicate the delay time. If this Retry-After message is not given, the client SHOULD handle it with a 500 response. Note: The existence of the 503 status code does not mean that the server must use it when overloaded. Some servers simply wish to reject the client's connection.
504When a server working as a gateway or proxy tries to execute a request, it fails to obtain a request from the upstream server (the server identified by the URI, such as HTTP, FTP, LDAP) or a secondary server (such as DNS) receives a response. Note: Some proxy servers will return a 400 or 500 error when a DNS query times out
505The server does not support, or refuses to support use in the request HTTP version of . This implies that the server cannot or will not use the same version as the client. The response SHOULD contain an entity describing why the version is not supported and which protocols the server supports.
506Extended by the Transparent Content Negotiation Protocol (RFC 2295) to indicate that the server has an internal configuration error: the requested negotiation argument resource was Configured to use itself in transparent content negotiation, so is not an appropriate focus in a negotiation process.
507The server was unable to store content necessary to complete the request. This condition is considered temporary. WebDAV(RFC 4918)
509The server has reached a bandwidth limit. This is not an official status code, but is still widely used.
510The strategy required to obtain the resource is not met.(RFC 2774)
your footprint: