This is the 17th day of my participation in Gwen Challenge
directory
- 1XX (temporary response) represents a status code for a temporary response that requires the requester to continue executing the operation.
- 2xx (success) indicates that the request’s status code was successfully processed.
- 3xx (redirect) indicates that further action is required to complete the request. Typically, these status codes are used for redirects.
- 4XX (Request error) These status codes indicate that the request may be in error, preventing the server from processing it.
- 5XX (Server Errors) These status codes indicate that an internal error occurred while the server was trying to process the request. These errors may be server errors rather than request errors.
1XX (temporary response) represents a status code for a temporary response that requires the requester to continue executing the operation.
100 (Continue) The requester should continue to make the request. The server returns this code to indicate that it has received the first part of the request and is waiting for the rest.
101 (Switching protocol) The requester has asked the server to switch protocol, and the server has confirmed and is ready to switch.
2xx (success) indicates that the request’s status code was successfully processed.
200 (Success) The server has successfully processed the request. Typically, this means that the server has provided the requested web page.
201 (Created) The request succeeded and the server created a new resource.
202 (Accepted) The server has accepted the request but has not yet processed it.
203 (Unauthorized Information) The server has successfully processed the request, but the information returned may come from another source.
204 (No content) The server successfully processed the request, but did not return any content.
205 (Reset Content) The server successfully processed the request, but did not return any content.
206 the server successfully processed some OF the GET requests.
3xx (redirect) indicates that further action is required to complete the request. Typically, these status codes are used for redirects.
300 (Multiple options) The server can perform a variety of operations on a request. The server can select an operation based on the requester (User Agent) or provide a list of operations for the requester to select.
The page for request 301 (Permanent move) has been permanently moved to a new location. When the server returns this response (a response to a GET or HEAD request), it automatically forwards the requester to the new location.
The 302 (temporary mobile) server currently responds to requests from web pages in different locations, but requesters should continue to use the original location for future requests.
303 (View other locations) The server returns this code when the requester should use a separate GET request for a different location to retrieve the response.
304 (Unmodified) The requested page has not been modified since the last request. When the server returns this response, the web page content is not returned.
305 (Using a proxy) The requester can only access the requested web page using a proxy. If the server returns this response, it also indicates that the requester should use a proxy.
307 (temporary redirection) The server currently responds to requests from web pages in different locations, but the requester should continue to use the original location for future requests.
4XX (Request error) These status codes indicate that the request may be in error, preventing the server from processing it.
400 (Error request) Server does not understand the syntax of the request.
The 401 (unauthorized) request requires authentication. The server may return this response for a web page that requires login.
403 (Forbidden) The server rejects the request.
404 (Not found) The server could not find the requested page.
405 (method disable) Disables the method specified in the request.
406 (Not accepted) Web pages that cannot respond to a request using the requested content feature.
407 (Proxy authorization required) This status code is similar to 401(unauthorized), but specifies that the requester should authorize the use of the proxy. 408 (Request Timeout) The server timed out while waiting for a request.
409 (Conflict) A server conflict while completing a request. The server must include information about the conflict in the response.
410 (Deleted) The server returns this response if the requested resource has been permanently deleted.
411 (Valid length required) The server will not accept requests that do not contain a valid content length header field.
412 (Conditions not met) The server does not meet one of the conditions set by the requester in the request.
413 (Request entity too large) The server cannot process the request because the request entity is too large for the server to handle.
414 (Request URI too long) The request URI(usually the url) is too long for the server to process.
415 (Unsupported media Type) The requested format is not supported by the requested page.
416 (Requested scope not required) If the page cannot provide the requested scope, the server returns this status code.
417 (Unmet expected value) The server did not meet the requirements for the “expected” request header field.
5XX (Server Errors) These status codes indicate that an internal error occurred while the server was trying to process the request. These errors may be server errors rather than request errors.
500 (Server internal error) The server encountered an error and could not complete the request.
The 501 (not yet implemented) server does not have the capability to complete requests. For example, the server may return this code if it does not recognize the request method.
502 (Error Gateway) server, acting as gateway or proxy, received invalid response from upstream server.
503 (Service unavailable) The server is currently unavailable (due to overloading or downtime for maintenance). Usually, this is a temporary state.
504 (Gateway Timeout) The server acted as a gateway or proxy, but did not receive the request from the upstream server in time.
505 (HTTP version not supported) The server does not support the HTTP protocol version used in the request.
In more detail
| Status code | meaning |
|---|---|
| 100 | The client should continue to send requests. This temporary response is used to inform the client that some of its requests have been received by the server and have not yet been rejected. The client should continue to send the rest of the request, or ignore the response if the request is completed. The server must send a final response to the client after the request completes. |
| 101 | The server has understood the client’s request and will inform the client via the Upgrade header that a different protocol is used to complete the request. After sending the blank line at the end of this response, the server will switch to the protocols defined in the Upgrade header. This should be done only when switching to a new protocol is more beneficial. For example, switching to a new VERSION of HTTP has advantages over an older version, or switching to a real-time and synchronous protocol to deliver resources that take advantage of such features. |
| 102 | Status code extended by WebDAV (RFC 2518), indicating that processing will continue. |
| 200 | The request was successful, and the desired response header or data body is returned with this response. |
| 201 | The request has been implemented, and a new resource has been created based on the requirements of the request and its URI has been returned with the Location header. If the required resource cannot be created in time, return ‘202 Accepted’. |
| 202 | The server has accepted the request but has not yet processed it. Just as it may be denied, ultimately 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 a response that returns a 202 status code is to allow the server to accept requests for other processes (such as a batch-based operation that is performed only once a day) without having to keep the client connected to the server until the batch operation is complete. A response that accepts request processing and returns a 202 status code should include in the returned entity some information indicating the current status of the processing, as well as Pointers to a process status monitor or state prediction so that the user can estimate whether the operation has completed. |
| 203 | The server has successfully processed the request, but the entity header meta-information returned is not a defined set valid on the original server, but a local or third-party copy. The current information may be a subset or superset of the original version. For example, metadata containing resources may cause the original server to know the super of meta information. Using this status code is not required and is only appropriate if the response would have returned 200 OK without using this status code. |
| 204 | The server successfully processed the request, 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 such header information exists, it should correspond to the requested variable. If the client is a browser, the user browser should retain the page from which the request was sent without any changes to the document view, even though according to the specification new or updated meta-information should be applied to the document in the user’s browser active view. Because the 204 response is prohibited from containing any message body, it always ends with the first blank line after the header. |
| 205 | The server successfully processed the request and did not return anything. But unlike the 204 response, the response that returns this status code requires the requester to reset the document view. This response is primarily used to reset the form immediately after receiving user input so that the user can easily start another input. Like the 204 response, this response is disallowed from containing any message body and ends with the first blank line after the header. |
| 206 | The server has successfully processed some of the GET requests. HTTP download tools such as FlashGet or Xunlei use this type of response to implement breakpoint continuation or break up a large document into multiple download segments at the same time. The request must contain a Range header indicating 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 indicates the Range of Content returned in the response; For multipart downloads with a Content-Type of Multipart/Byteranges, each multipart should contain a Content-range field indicating the Content Range of the segment. If the response contains Content-Length, its value must match the true number of bytes in the Content range it returns. Date ETag and/or Content-location, if the same request should have returned 200. Expires, Cache-control, and/or Vary, if their values may differ from those corresponding to other previous responses of the same variable. If the response request uses if-range strong cache validation, then the response should not contain other entity headers. If the request for this response uses if-range weak cache validation, then the response is prohibited from including other entity headers. This avoids inconsistencies between cached entity content and updated entity header information. Otherwise, the response should contain all of the entity header fields that should have been returned in the 200 response. If the ETag or Last-Modified headers do not exactly match, the client cache should prohibit combining the 206 response returned with any previously cached content. Any cache that does not support Range and Content-range headers disallows caching of the 206 response. |
| 207 | The status code, extended by WebDAV(RFC 2518), 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 sub-requests. |
| 300 | The requested resource has a selection of 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 the entity of a list of resource attributes and addresses from which the user or browser can select 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 capabilities. Of course, the RFC 2616 specification does not specify how such automatic selection should be performed. If the server already has a preferred feedback option, specify the FEEDBACK URI in the Location; The browser may use this Location value as the address for automatic redirection. In addition, the response is also cacheable unless otherwise specified. |
| 301 | The requested resource has been permanently moved to the new location, and any future references to this resource should use one of the several URIs returned by this response. If possible, clients with link editing capabilities should automatically change the requested address to the one that is returned from the server. Unless otherwise specified, the response is also cacheable. The new persistent URI should be returned in the Location field of the response. Unless this is a HEAD request, the entity responding should contain a hyperlink to the new URI with a short description. If this is not a GET or HEAD request, the browser forbids automatic redirection unless the user confirms it, because the conditions of the request may change. Note: For some browsers using HTTP/1.0, if they send a POST request and GET a 301 response, subsequent redirects will become GET requests. |
| 302 | The requested resource now temporarily responds to the request from a different URI. Since such redirects are temporary, the client should continue to send future requests to the original address. The 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 responding should contain a hyperlink to the new URI with a short description. If this is not a GET or HEAD request, the browser forbids automatic redirection unless the user confirms it, because the conditions of the request may change. Note: Although the RFC 1945 and RFC 2068 specifications do not allow clients to change the request method during redirection, many existing browsers treat a 302 response as a 303 response and use GET to access the URI specified in Location, ignoring the original request method. Status codes 303 and 307 have been added to specify what 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 the output of POST requests activated by the script to be redirected to a new resource. This new URI is not a substitute reference to the original resource. At the same time, 303 responses are prohibited from being cached. Of course, the second request (redirection) may be cached. The new URI should be returned in the Location field of the response. Unless this is a HEAD request, the entity responding should contain a hyperlink to the new URI with a short description. Note: Many browsers prior to HTTP/1.1 do not understand 303 status correctly. If you need to consider interactions with these browsers, the 302 status code should do the job, because most browsers handle 302 responses exactly as the specification requires clients to handle 303 responses. |
| 304 | If the client sends a conditional GET request and the request is granted, the content of the document has not changed (since the last access or according to the conditions of the request), the server should return this status code. The 304 response disallows the inclusion of a message body and therefore always ends with the first blank line after the message header. The response must contain the following header: Date, unless the server does not have a clock. If the clock-less server follows these rules, the proxy server and client can add the Date field to the received response header (as specified in RFC 2068), and the caching mechanism will work fine. ETag and/or Content-location, if the same request should have returned 200. Expires, Cache-control, and/or Vary, if their values may differ from those corresponding to other previous responses of the same variable. If this response request uses strong cache validation, then this response should not contain other entity headers; Otherwise (for example, if a conditional GET request uses weak cache validation), the response is prohibited from including other 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 constraint. 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 updated in the response. |
| 305 | The requested resource must be accessed through the specified proxy. The Location field gives the URI information for the specified proxy, and the receiver needs to send a separate request repeatedly to access the resource through this proxy. Only the original server can establish the 305 response. Note: RFC 2068 does not specify that the 305 response is to redirect a single request and can only be established by the original server. Ignoring these restrictions can have serious security consequences. |
| 306 | In the latest version of the specification, the 306 status code is no longer used. |
| 307 | The requested resource now temporarily responds to the request from a different URI. Since such redirects are temporary, the client should continue to send future requests to the original address. The 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 responding should contain a hyperlink to the new URI with a short description. Because some browsers do not recognize the 307 response, you need to add the necessary information so that users can understand and request access to the new URI. If this is not a GET or HEAD request, the browser forbids automatic redirection unless the user confirms it, because the conditions of the request may change. |
| 400 | The current request cannot be understood by the server. The client should not re-submit this request unless it is modified. 2. The request parameters are incorrect. |
| 401 | The current request requires user authentication. The response must include a WWW-Authenticate header applicable to the requested resource to ask for user information. The client can repeatedly submit a request with the appropriate Authorization header information. If the current request already contains Authorization certificates, the 401 response represents server validation that has rejected those certificates. If the 401 response contains the same authentication query as the previous response, and the browser has attempted authentication at least once, 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 understands the request, but refuses to execute it. Unlike the 401 response, authentication does not help, and the request should not be submitted twice. If this is not a HEAD request and the server wants to be able to explain why the request cannot be executed, 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. |
| 404 | 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 is aware of the situation, it should use the 410 status code to tell the old resource that it is permanently unavailable due to some internal configuration mechanism and that there are no reachable addresses. 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. |
| 405 | The request method specified in the request line cannot be used to request the corresponding resource. The response must return an Allow header representing a list of request methods that the current resource can accept. Because the PUT and DELETE methods write to the resources on the server, most web servers do not support or do not allow these methods by default, and return 405 errors for such requests. |
| 406 | The content characteristics of the requested resource do not satisfy the condition in the request header, and therefore the response entity cannot be generated. Unless this is a HEAD request, the response should return an entity with an address list that allows the user or browser to select the most appropriate entity feature from the list. 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 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 on the proxy server. The Proxy server must return a proxy-authenticate for identity questioning. The client can return a proxy-authorization header for authentication. See RFC 2617. |
| 408 | The request timed out. The client did not finish sending a request within the time the server was waiting. The client can submit this request again at any time without making any changes. |
| 409 | The request could not be completed because of a conflict with the current state of the requested resource. This code is allowed to be used only when the user is deemed capable of resolving 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, if the version information accompanying a PUT request to modify a particular resource conflicts with a previous (third-party) request, the server should return a 409 error informing the user that the request could not be completed. At this point, the response entity is likely to contain a comparison of the differences between the two conflicting versions so that the user can resubmit the new version after merging. |
| 410 | The requested resource is no longer available on the server and does not have any known forwarding address. Such conditions 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, the 404 status code should be used. Unless otherwise noted, the response is cacheable. The main purpose of the 410 response is to help the webmaster maintain the site by notifying the user that the resource is no longer available and that the server owner wants all remote connections to the resource to be removed. Such events are common in time-limited, value-added services. Similarly, the 410 response is used to inform clients that resources that once belonged 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 to keep that mark for how long. |
| 411 | The server refuses to accept a request without defining the Content-Length header. After adding a valid Content-Length header indicating the Length of the request message body, the client can submit the request again. |
| 412 | The server failed to meet one or more of the prerequisites when verifying that they were given in the header field of the request. This status code allows a client to set a prerequisite in the request meta-information (request header field data) when acquiring a resource, preventing the request method from being applied to a resource other than its desired content. |
| 413 | The server refused to process the current request because the size of entity data submitted by the request was larger than the server was willing or able to process. In this case, the server can close the connection to prevent the client from continuing to send the request. If the condition is temporary, the server should return a retry-after response header to tell the client how long it can Retry. |
| 414 | The request URI was longer than the server could interpret, so the server refused to service the request. This is rare. Common cases include a form submission that should have used POST instead of GET, resulting in a Query String that is too long. Redirection URI “black holes”, such as the old URI being part of the new one with each redirection, result in the URI being too long after several redirects. The client is trying to exploit a security vulnerability in some servers. Such servers use a fixed-length buffer to read or manipulate the URI of the request, and when the parameters after GET exceed a certain value, a buffer overflow may occur, causing arbitrary code to be executed [1]. Servers without such vulnerabilities should return a 414 status code. |
| 415 | For the currently requested method and requested resource, the submitted entity in the request is not in a format supported by the server, so the request is rejected. |
| 416 | If the request contains a Range header, any data Range specified in the Range does not overlap with the available Range of the current resource, and If an IF-range header is not defined in the request, the server should return a 416 status code. If Range uses a byte Range, then the first byte positions of all data ranges specified by the request exceed the length of the current resource. The server should also return a 416 status code with a Content-Range entity header that indicates the length of the current resource. The response is also disallowed from using multipart/ Byteranges as its content-Type. |
| 417 | The expected content specified in request header Expect cannot be satisfied by the server, or the server is a proxy server that has clear evidence that Expect’s content cannot be satisfied at the next node of the current route. |
| 421 | The number of connections to the server from the current client’s IP address exceeded the maximum allowed by the server. In general, the IP address here refers to the client address seen from the server (such as the user’s gateway or proxy server address). In this case, the connection count calculation may involve more than one end user. |
| 422 | The number of connections to the server from the current client’s IP address exceeded the maximum allowed by the server. In general, the IP address here refers to the client address seen from the server (such as the user’s gateway or proxy server address). In this case, the connection count calculation may involve more than one end user. |
| 422 | The request was well-formed, but could not be responded to due to semantic errors. (RFC 4918 WebDAV) 423 Locked The current resource is Locked. (RFC 4918 WebDAV) |
| 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 not in the WebDav Sequential Set Protocol (RFC 3658). |
| 426 | The client should switch to TLS/1.0. (RFC 2817) |
| 449 | Extended by Microsoft to mean that the request should be retried after the appropriate action has been performed. |
| 500 | The server encountered an unexpected condition that prevented it from completing processing the request. Typically, this problem occurs when the server’s code fails. |
| 501 | The server does not support a feature required for the current request. When the server does not recognize the requested method and cannot support its request for any resource. |
| 502 | An invalid response was received from the upstream server when a server working as a gateway or proxy tried to execute the request. |
| 503 | The server is currently unable to process requests due to temporary server maintenance or overload. The situation is temporary and will recover over time. If the delay time is 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 process it as if it were a 500 response. Note: the presence of a 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 | When a server working as a gateway or proxy tries to execute a request, it fails to receive a response from an upstream server (a server identified by a URI, such as HTTP, FTP, or LDAP) or a secondary server (such as DNS) in a timely manner. Note: Some proxy servers will return 400 or 500 errors when DNS queries time out |
| 505 | The server does not support, or refuses to support, the HTTP version used in the request. This implies that the server cannot or will not use the same version as the client. The response should include an entity that describes why the version is not supported and which protocols are supported by the server. |
| 506 | Extended by the Transparent Content Negotiation Protocol (RFC 2295), this means that the server has an internal configuration error: the requested negotiated argument resource is configured to use itself in transparent content negotiation and is therefore not an appropriate focus in a negotiation processing. |
| 507 | The server could not store the content necessary to complete the request. The situation is considered temporary. WebDAV (RFC 4918) |
| 509 | The server reached the bandwidth limit. Procedure This is not an official status code, but it is still widely used. |
| 510 | The strategy required to acquire the resource is not met. (RFC 2774) |
More related articles and my contact information I put here: gitee.com/haiyongcsdn… github.com/wanghao221/
And finally, don’t forget ❤ or 📑