Summary of common status codes for IOS HTTP requests
1xx message
This type of status code means that the request has been accepted and needs to be processed. This type of response is a temporary response, which contains only the status line and some optional response header information, and ends with a blank line. Since no 1xx status code is defined in the HTTP/1.0 protocol, the server prohibits sending 1xx responses to such clients unless under certain experimental conditions. The responses represented by these status codes are informative, indicating other actions the client should take.
100 Continue
The client should continue to send the request. This temporary response is used to notify the client that some of its requests have been received by the server and have not been rejected. The client should continue to send the rest of the request or ignore this response if the request has been completed. The server must send a final response to the client after the request is completed.
101 Switching Protocols
The server has understood the client's request and will notify the client to use a different protocol to complete the request through the Upgrade message header. After sending the last blank line of this response, the server will switch 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 is more advantageous than an older version, or switching to a real-time and synchronous protocol to deliver resources that take advantage of such features.
102 Processing
The status code extended by WebDAV (RFC 2518) means that the processing will continue to be executed.
2xx success
This type of status code means that the request has been successfully received, understood and accepted by the server.
200 OK
The request has been successful and the request's desired response header or data body will be returned with this response.
201 Created
The request has been implemented, and a new resource has been created according to the request needs, and its URI has been returned with the Location header information. If the required resources cannot be created in time, '202 Accepted' should be returned.
202 Accepted
The server has accepted the request, but has not been processed yet. Just as it may be denied, the request may or may not be executed eventually. In the case of asynchronous operation, there is no more convenient way to send this status code. : The purpose of returning a 202 status code response is to allow the server to accept requests from other processes (such as a batch-based operation that only performs once a day), without having to keep the client connected to the server until the batch operation is complete. The response to accepting the request processing and returning the 202 status code should include some information in the returned entity indicating the current status of processing, and a pointer to the processing status monitor or status prediction so that the user can estimate whether the operation has been completed.
203 Non-Authoritative Information
The server has successfully processed the request, but the returned entity header meta information is not a valid set of determinations 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 version. For example, metadata containing resources may cause the original server to know a superset of meta information. Using this status code is not necessary, and it is only appropriate if the response returns 200 OK without using this status code.
204 No Content
The server successfully processed the request, but did not need to return any entity content, and hoped to return updated meta information. The response may return new or updated meta information in the form of an entity header. If these header information exists, it should echo the requested variable.
If the client is a browser, the user's browser should retain the page where the request was sent without any changes in the document view, even if new or updated meta information should be applied to the document in the user's browser's active view according to the specification.
Since the 204 response is prohibited from containing any message body, it always ends with the first blank line after the message header.
205 Reset Content
The server successfully processed the request and returned nothing. But unlike the 204 response, the response returning 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, the response is also prohibited from containing any message body and ends with the first blank line after the message header.
206 Partial Content
The server has successfully processed some GET requests. HTTP download tools like FlashGet or Thunder use this type of response to achieve breakpoint continuous transmission or decompose a large document into multiple download segments to download simultaneously.
The request must contain Range header information to indicate the content range the client wants to get, and may contain If-Range as a request condition.
The response must contain the following header domain:
Content-Range is used to indicate the range of content returned in this response; if Content-Type is multipart/byteranges, each multipart segment should contain a Content-Range field to indicate the range of content of this 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 responses.
Expires, Cache-Control, and/or Vary, if their values may differ from the values 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 the request of this response uses If-Range weak cache verification, then this response prohibits including other entity headers; this response avoids inconsistencies between the cached entity content and the updated entity header information. Otherwise, this response should contain all entity header fields that should be returned in the 200 response.
If the ETag or Last-Modified headers cannot match exactly, the client cache should prohibit combining the content returned by the 206 response with any previously cached content.
Any cache that does not support Range and Content-Range headers prohibits cached content returned by 206 response.
207 Multi-Status
The status code extended by WebDAV (RFC 2518) represents that the subsequent message body will be an XML message, and may contain a series of independent response codes depending on the number of previous subrequests.
3xx redirection
This type of status code means that further actions are required by the client to complete the request. Usually, these status codes are used to redirect, and the subsequent request address (redirection target) is indicated in the Location field of this response.
If and only if the method used by subsequent requests is GET or HEAD, the user browser can automatically submit the required subsequent request without user intervention. Clients should automatically monitor infinite loop redirects (for example: A→B→C→…→A or A→A) because this will cause a large amount of unnecessary resource consumption by the server and client. According to the HTTP/1.0 specification, browsers should not automatically access redirects more than 5 times.
300 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 can select a preferred address for redirection.
Unless this is a HEAD request, the response should include an entity of a list of resource characteristics and addresses so that the user or browser can select the most appropriate redirect address from it. 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 response format and the browser's own capabilities. Of course, the RFC 2616 specification does not specify how such automatic selection should be performed.
If the server itself already has a preferred feedback choice, the URI of this feedback should be specified in the Location; the browser may use this Location value 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 the new location, and any future reference to this resource should use one of several URIs returned by this response. If possible, the client with link editing function should automatically modify the requested address to the address fed back from the server. Unless otherwise specified, this response is cacheable.
The new permanent URI should be returned in the response Location field. Unless this is a HEAD request, the responding entity should contain a hyperlink to the new URI and a brief description.
If this is not a GET or HEAD request, the browser prohibits automatic redirection unless it is confirmed by the user, because the conditions of the request may change as a result.
Note: For some browsers using the HTTP/1.0 protocol, when the POST request they send receives a 301 response, the subsequent redirect request will become a GET method.
302 Found
The requested resource now temporarily responds to the request from a different URI. Since such redirection is 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 response Location field. Unless this is a HEAD request, the responding entity should contain a hyperlink to the new URI and a brief description.
If this is not a GET or HEAD request, the browser prohibits automatic redirection unless it is confirmed by the user, because the conditions of the request may change as a result.
Note: Although the RFC 1945 and RFC 2068 specifications do not allow clients to change the request method during redirection, many existing browsers regard the 302 response as the 303 response and use the GET method to access the URI specified in Location, ignoring the original requested method. Status codes 303 and 307 are added to clarify what kind of reaction the server expects the client to perform.
303 See Other
The response corresponding to the current request can be found on another URI, and the client should access that resource in GET. This method exists mainly to allow the POST request output activated by the script to be redirected to a new resource. This new URI is not an alternative reference to the original resource. At the same time, the 303 response is prohibited from being cached. Of course, the second request (redirection) may be cached.
The new URI should be returned in the response Location field. Unless this is a HEAD request, the responding entity should contain a hyperlink to the new URI and a brief description.
Note: Many browsers before HTTP/1.1 cannot correctly understand the 303 status. If interactions with these browsers need to be considered, the 302 status code should be competent, because most browsers handle 302 responses exactly what the above specifications require clients to do when processing 303 responses.
304 Not Modified
If the client sends a conditional GET request and the request has been allowed, and the content of the document (since the last access or based on the requested conditions) has not changed, the server should return this status code. The 304 response prohibits the inclusion of the message body, so it always ends with the first blank line after the message header.
The response must contain the following header information:
Date, unless this server has no clock. If a server without a clock also complies with these rules, the proxy server and client can add the Date field to the received response header by itself (as specified in RFC 2068), and the cache mechanism will work properly.
ETag and/or Content-Location, if the same request should have returned 200 responses.
Expires, Cache-Control, and/or Vary, if their values may differ from the values corresponding to other responses of the same variable before.
If this response request uses strong cache verification, then this response should not contain other entity headers; otherwise (for example, a conditioned GET request uses weak cache verification), this response prohibits other entity headers; this avoids inconsistency between cached entity content and updated entity header information.
If a 304 response indicates that the current entity is not cached, the cache system must ignore this response and repeatedly send requests that do not contain restrictions.
If a 304 response is received that requires an update of a cache entry, the cache system must update the entire entry to reflect the values of all fields updated in the response.
305 Use Proxy
The requested resource must be accessed through the specified proxy. The URI information of the specified proxy is given in the Location field. The recipient needs to repeatedly send a separate request to access the corresponding resource through this proxy. Only the original server can create a 305 response.
Note: There is no explicit 305 response in RFC 2068 to redirect a separate request and can only be created by the original server. Ignoring these restrictions can lead to serious safety consequences.
306 Switch Proxy
In the latest version of the specification, the 306 status code is no longer used.
307 Temporary Redirect
The requested resource now temporarily responds to the request from a different URI. Since such redirection is 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 response Location field. Unless this is a HEAD request, the responding entity should contain a hyperlink to the new URI and a brief description. Because some browsers cannot recognize the 307 response, the necessary information above needs to be added so that the user can understand and issue an access request to the new URI.
If this is not a GET or HEAD request, the browser prohibits automatic redirection unless it is confirmed by the user, because the conditions of the request may change as a result.
4xx client error
This type of status code means that the client may seem to have an error, which hinders the server's processing. Unless it responds to a HEAD request, the server should return an entity that explains the current error status, and whether it is temporary or permanent status. These status codes are suitable for 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 closing the connection between the client and the server. If the client continues to send data to the server after receiving the error message, the server's TCP stack will send a reset packet to the client to clear all input buffers that have not been identified by the client, so that the data is not read and interfered with by the application on the server.
400 Bad Request
Due to the syntax error, the current request cannot be understood by the server. The client should not submit this request repeatedly unless it is modified.
401 Unauthorized
The current request requires user verification. The response must contain a WWW-Authenticate header for the requested resource to ask for user information. The client can repeatedly submit a request containing the appropriate Authorization header information. If the current request already contains the Authorization certificate, then the 401 response means that the server verification has rejected those certificates. If the 401 response contains the same authentication inquiry as the previous response, and the browser has tried at least one verification, the browser should show the user the entity information contained in the response, because the entity information may contain relevant diagnostic information. See RFC 2617.
402 Payment Required
This status code is reserved for possible future needs.
403 Forbidden
The server has understood the request, but refuses to execute it. Unlike the 401 response, authentication does not provide any help, and this request should not be submitted repeatedly. 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 obtain any information.
404 Not Found
The request failed and the resource you want to obtain was not discovered on the server. There is no information to tell the user whether this situation is temporary or permanent. If the server knows the situation, it should use the 410 status code to inform the old resource that it has been permanently unavailable due to some internal configuration mechanism problems, and there is no address that can be redirected. 404 This status code is widely used when the server does not want to reveal why the request was denied or no other suitable response is available.
405 Method Not Allowed
The request method specified in the request line cannot be used to request the corresponding resource. The response must return an Allow header information to indicate a list of request methods that the current resource can accept.
Given that PUT, the DELETE method will write to resources on the server, so most web servers do not support or do not allow the above request method under the default configuration, and will return a 405 error for such requests.
406 Not Acceptable
The content characteristics 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 that contains the most appropriate entity characteristics and address lists that allow the user or browser to select from. The format of an entity is determined by the media type defined in the Content-Type header. The browser can make the best choices based on the format and its own capabilities. However, no criteria for making such automatic selection are defined in the specification.
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 for identity inquiry. The client can return a Proxy-Authorization header for verification. See RFC 2617.
408 Request Timeout
Request timeout. The client does not complete the sending of a request within the server's ready waiting time. The client can submit this request again at any time without any changes.
409 Conflict
Due to a conflict with the current state of the requested resource, the request cannot be completed. This code is only allowed to be used in such a situation: the user is considered to be able to resolve conflicts 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 adopted, the version information attached to the 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 informing the user that the request cannot be completed. At this point, it is likely that the response entity will contain a differential comparison between the two conflicting versions so that the user can resubmit the merged new version.
410 Gone
The requested resource is no longer available on the server and does not have any known forwarding addresses. Such a situation should be considered permanent. If possible, clients with link editing capabilities should delete all references to this address after obtaining user permission. If the server does not know or cannot determine whether the status is permanent, then a 404 status code should be used. Unless otherwise stated, this response is cacheable.
The purpose of the 410 response is mainly to help the website administrator maintain the website, notify the user that the resource is no longer available, and that the server owner hopes that all remote connections pointing to this resource will also be deleted. This type of incident is very common in limited-time and value-added services. Similarly, the 410 response is also used to notify the client that the resources originally belonging to a certain individual are no longer available on the current server site. Of course, whether all permanently unavailable resources need to be marked as '410 Gone' and whether it needs to be kept for how long it will be entirely up to the server owner.
411 Length Required
The server refuses to accept requests 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 Precondition Failed
The server failed to satisfy one or more of them when verifying that the prerequisites are given in the request header field. This status code allows the client to set prerequisites in the requested meta-information (request header field data) when obtaining the resource, thereby preventing the request method from being applied to resources other than its desired content.
413 Request Entity Too Large
The server refuses to process the current request because the size of the entity data submitted by the request exceeds the range the server is willing or able to process. In this case, the server can close the connection so that the client can continue to send the request.
If this condition is temporary, the server should return a Retry-After response header to tell the client how long it can be retryed.
414 Request-URI Too Long
The requested URI length exceeds the length that the server can interpret, so the server refuses to provide service to the request. This is relatively rare, and usually includes:
The form submission that should have used the POST method becomes a GET method, resulting in the query string being too long.
Redirecting URI "black holes" such as using the old URI as part of the new URI each time, resulting in a URI that is super long after several redirects.
The client is trying to exploit security vulnerabilities present in some servers to attack the server. This type of server uses a fixed-length buffer to read or operate the requested URI. When the parameters after GET exceed a certain value, buffer overflow may occur, resulting in arbitrary code being executed [1]. Servers without such vulnerabilities should return a 414 status code.
415 Unsupported Media Type
For the currently requested method and the requested resource, the entity submitted in the request is not the supported format in the server, so the request is denied.
416 Requested Range Not Satisfiable
If the request contains a Range request header, and any data range specified in the Range does not coincide with the available range of the current resource, and 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 current resource length. The server should also include a Content-Range entity header while returning the 416 status code to indicate the length of the current resource. This response is also prohibited from using multipart/byteranges as its Content-Type.
417 Expectation Failed
The expected content specified in the request header Expect cannot be satisfied by the server, or this server is a proxy server, which has obvious evidence that the content of Expect cannot be satisfied on the next node of the current route.
418 I'm a teapot
This opcode was defined in 1998 as a traditional April Fools' Day joke for the IETF, in the RFC 2324 Hypertext Coffee Pot Control Protocol and does not need to be defined in a real HTTP server.
421 There are too many connections from your internet address
The number of connections from the IP address where the current client resides to the server exceeds the maximum range of server permissions. Generally, 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 calculation of the number of connections may involve more than one end user.
422 Unprocessable Entity
The request is of correct format, but it cannot respond due to semantic errors. (RFC 4918 WebDAV)
423 Locked
The current resource is locked. (RFC 4918 WebDAV)
424 Failed Dependency
Due to an error occurred in a previous request, the current request failed, such as PROPPATCH. (RFC 4918 WebDAV)
425 Unordered Collection
Defined in the WebDav Advanced Collections draft, but not in the WebDAV Sequential Set Protocol (RFC 3658).
426 Upgrade Required
The client should switch to TLS/1.0. (RFC 2817)
449 Retry With
Extended by Microsoft, it means that the request should be retryed after the appropriate operation is performed.
5xx server error
This type of status code represents an error or abnormal state occurred during the server processing the request, and it may also be that the server realizes that the current software and hardware resources cannot complete the processing of the request. Unless this is a HEAD request, the server should include an interpreter information entity that explains the current error status and whether the status is temporary or permanent. The browser should show the user any entity contained in the current response.
These status codes are suitable for any response method.
500 Internal Server Error
The server encountered an unexpected situation, which caused it to be unable to complete the processing of the request. Generally speaking, this problem will occur when the server's program code errors.
501 Not Implemented
The server does not support a certain function required for the current request. When the server cannot recognize the requested method and cannot support its request for any resource.
502 Bad Gateway
When a server working as a gateway or agent tries to execute a request, an invalid response is received from the upstream server.
503 Service Unavailable
Due to temporary server maintenance or overload, the server is currently unable to process the request. This condition is temporary and will recover after a period of time. If the delay time can be estimated, a Retry-After header can be included in the response to indicate the delay time. If this Retry-After information is not given, the client should process it in a way that handles 500 responses.
504 Gateway Timeout
When a server working as a gateway or proxy attempts to execute a request, it fails to receive a response from the upstream server (server identified by the URI, such as HTTP, FTP, LDAP) or auxiliary server (such as DNS).
Note: Some proxy servers will return 400 or 500 errors when 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 is unwilling 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 Agreement (RFC 2295), it represents an internal configuration error in the server: the requested negotiated argument resource is configured to use itself in transparent content negotiation, so it is not a suitable focus in a negotiation process.
507 Insufficient Storage
The server cannot store the content necessary to complete the request. This situation is considered temporary. WebDAV (RFC 4918)
509 Bandwidth Limit Exceeded
The server has reached bandwidth limit. This is not an official status code, but it is still widely used.
510 Not Extended
The strategy required to obtain resources is not unsatisfied.
Thank you for reading, I hope it can help you. Thank you for your support for this site!