Parsing HTTP (HttpURLConnection getresponsecode)

HTTP Request

The client requests access to the resource to the server by sending an HTTP request. The HTTP request consists of three parts: the request line, the message header, and the request for essay.

3.1. Request Line

The request line begins with a method symbol, followed by the request URI and the version of the protocol, ending with CRLF (which means carriage return line wrapping). The request lines are separated by spaces, except that a separate CR or LF character is not allowed in addition to the end of the CRLF. The format is as follows:

Method Request-uri http-version CRLF

For example:

Get/form.html http/1.1 (CRLF)

Method

In the HTTP protocol, HTTP requests can use a variety of request methods that indicate how to access the resources identified by Request-uri. The request methods supported by HTTP1.1 are shown in the following table:

How to request in HTTP1.1

Method	Role
GET	Request to get the resource identified by Request-uri
POST	The requesting server receives the entity encapsulated in the request as part of the resource identified by Request-uri in Request-line
HEAD	Request for a response message header for a resource identified by Request-uri
PUT	The request server stores a resource and uses Request-uri as its identifier
DELETE	Requesting the server to delete resources identified by Request-uri
TRACE	Request information to be echoed back to the requesting server, primarily for testing or diagnostics
CONNECT	Reserved for future use
OPTIONS	Request performance of the query server, or query for resource-related options and requirements

Describes the three methods of GET, POST, and HEAD:

(1) GET

GET Request-uri http/1.1

When we visit a webpage by entering the URL directly in the address bar of the browser, the browser uses the Get method to get the resources from the server.

(2) POST

The POST method is used to make a request to the destination server to request that the server receive the data appended to the request. The Post method is used more when the form is submitted, here is an example of submitting a form using the Post method:

Submit a form using the POST method

post/reg.jsp http/1.1 (CRLF)

Accept:image/gif, Image/x-xbit, ... (CRLF)

HOST:www.winsunlight.com (CRLF)

Content-length:22 (CRLF)

Connection:keep-alive (CRLF)

Cache-control:no-cache (CRLF)

(CRLF)

user = zhangsan&pwd=123456

After the two carriage return is wrapped, the data is submitted by the form.

(3) HEAD

The head method is almost identical to the GET method, except that the head method simply requests the message header rather than the complete content. For the response part of the head request, the information contained in the HTTP header is the same as the information obtained through the GET request. Using this method, you can  about the resources identified by Request-uri without transmitting the entire resource content. This method is often used to test the validity of hyperlinks, whether they can be accessed, and whether they have been updated recently.

When we submit a form in HTML, the browser makes a request to the server based on whether you submit it as a GET or post, using the appropriate get or POST method in the HTTP protocol. Note that in an HTML document, both Get and post are written, but the get and post in the HTTP protocol can only be uppercase.

3.2. Message header

3.3. Request Body

Between the message header and the request body is a blank line (with only one CRLF line), which indicates that the message header has ended, followed by the request body. The request body can contain the submitted data, in the above example, user = zhangsan&pwd=123456 is the request body part.

4. HTTP response

After the request message is received and interpreted, the server returns an HTTP response message. Like an HTTP request, the HTTP response is also made up of three parts: the status line, the message header, and the response body.

4.1, status line

The status line consists of a protocol version, a status code in the form of a number, and a corresponding state description, separated by a space between the elements, and the CR or LF characters are not allowed except for the trailing CRLF (carriage return) character sequence. The format is as follows:

Http-version Status-code reason-phrase CRLF

Http-version represents the version of the server HTTP protocol, Status-code represents the response code sent back by the server, Reason-phrase represents the text description of the status code, and CRLF represents a carriage return line break. For example:

http/1.1 OK (CRLF)

Status Codes and status descriptions

The status code consists of 3 digits that indicate whether the request is understood or satisfied, and the status description gives a brief textual description of the status code. The first number of the status code defines the response category, and the following two digits are not categorized. The first number has 5 values, as shown below.

• 1XX: Indication information-Indicates that the request has been accepted and continues processing
• 2XX: Success-Indicates that the request has been successfully received, understood, accepted.
• 3XX: Redirect--further action is required to complete the request
• 4XX: Client Error--Request syntax error or request not implemented
• 5XX: Server-side error-the server failed to implement a legitimate request.

status codes and status descriptions in HTTP1.1

Status code	Status information	Meaning
100	Continue	The initial request has been accepted and the customer should continue to send the remainder of the request. (HTTP 1.1 new)
101	Switching protocols	The server translates the client's request to another protocol (HTTP 1.1 new)
200	Ok	Everything is OK, the answer document for Get and post requests is followed.
201	Created	The server has created the document, and the location header gives its URL.
202	Accepted	The request has been accepted, but the processing has not been completed.
203	Non-authoritative Information	The document has returned normally, but some of the answer headers may be incorrect because a copy of the document is being used (HTTP 1.1 is new).
204	No Content	Without a new document, the browser should continue to display the original document. This status code is useful if the user refreshes the page on a regular basis and the servlet can determine that the user's document is new enough.
205	Reset Content	There is no new content, but the browser should reset what it displays. Used to force the browser to clear the form input (HTTP 1.1 new).
206	Partial Content	The client sends a GET request with a range header, and the server finishes it (HTTP 1.1 is new).
300	Multiple Choices	The documents requested by the customer can be found in multiple locations that are listed in the returned document. If the server wants to make a preference, it should be indicated in the location answer header.
301	Moved Permanently	The document requested by the customer elsewhere, the new URL is given in the location header, and the browser should automatically access the new URL.
60W	Found	Similar to 301, but the new URL should be treated as a temporary replacement instead of permanent. Note that the corresponding status information in HTTP1.0 is "Moved temporatily". When the status code appears, the browser can automatically access the new URL, so it is a useful status code. Note that this status code can sometimes be used with 301 substitutions. For example, if the browser mistakenly requests Http://host/~user (the trailing slash is missing), some servers return 301, and some return 302. Strictly speaking, we can only assume that the browser will automatically redirect only if the original request is get. See 307.
303	See other	Similar to 301/302, the difference is that if the original request is the Post,location header the specified redirect target document should be fetched via get (HTTP 1.1 new).
304	Not Modified	The client has a buffered document and issues a conditional request (typically providing a if-modified-since header indicating that the customer only wants to update the document than the specified date). The server tells the customer that the original buffered document can continue to be used.
305	Use Proxy	The document requested by the client should be extracted from the proxy server indicated by the location header (HTTP 1.1 is new).
307	Temporary Redirect	Same as 302 (Found). Many browsers incorrectly respond to a 302 response for redirection, even if the original request is post, even though it can actually be redirected only if the answer to the POST request is 303. For this reason, HTTP 1.1 has been added in 307 to allow for more cleanup of the region in several status codes: When a 303 response occurs, the browser can follow the redirected get and post requests, and if the 307 answer, the browser can only follow the redirect to the GET request. (HTTP 1.1 new)
400	Bad Request	A syntax error occurred in the request.
60s	Unauthorized	The customer attempted to access a password-protected page without authorization. A www-authenticate header is included in the answer, and the browser displays the user name/Password dialog box, and then makes a request again after filling in the appropriate authorization header.
403	Forbidden	The resource is not available. The server understands the customer's request, but refuses to process it. This is usually caused by the permissions set on the file or directory on the server.
404	Not Found	The resource at the specified location could not be found. This is also a common answer.
405	Method not allowed	The request method (GET, POST, HEAD, DELETE, PUT, Trace, and so on) does not apply to the specified resource. (HTTP 1.1 new)
50W	Not acceptable	The specified resource has been found, but its MIME type is incompatible with the client specified in the Accpet header (HTTP 1.1 new).
407	Proxy Authentication Required	Similar to 401, indicates that the customer must be authorized by the proxy server first. (HTTP 1.1 new)
408	Request Timeout	The customer has not made any requests during the waiting time for the server license. Customers can repeat the same request at a later time. (HTTP 1.1 new)
409	Conflict	Usually related to put requests. The request cannot succeed because the request conflicts with the current state of the resource. (HTTP 1.1 new)
410	Gone	The requested document is no longer available, and the server does not know which address to redirect to. It differs from 404 in that returning 407 means that the document has permanently left the specified location, and 404 indicates that the document is unavailable for unknown reasons. (HTTP 1.1 new)
411	Length Required	The server cannot process the request unless the customer sends a content-length header. (HTTP 1.1 new)
412	Precondition Failed	Some of the prerequisites specified in the request header failed (HTTP 1.1 new).
413	Request Entity Too Large	The size of the destination document exceeds the size that the server is currently willing to handle. If the server thinks it can process the request later, it should provide a Retry-after header (HTTP 1.1 new).
414	Request URI Too Long	The URI is too long (HTTP 1.1 new).
416	Requested Range not satisfiable	The server does not meet the range header specified by the customer in the request. (HTTP 1.1 new)
500	Internal Server Error	The server encountered an unexpected situation and could not complete the customer's request.
501	Not implemented	The server does not support the functionality required to implement the request. For example, a customer sends a put request that is not supported by the server.
502	Bad Gateway	When the server acts as a gateway or proxy, the server returns an illegal response in order to complete the request to access the next server.
503	Service unavailable	The server failed to answer due to maintenance or heavy load. For example, a servlet might return 503 if the database connection pool is full. A retry-after header can be supplied when the server returns 503.
504	Gateway Timeout	Used by a server acting as a proxy or gateway, indicating that an answer cannot be received from a remote server in a timely manner. (HTTP 1.1 new)
505	HTTP Version not supported	The HTTP version indicated in the request is not supported by the server. (HTTP 1.1 new)

1XX message

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

Continue

The client should continue to send the request. This temporary response is used to inform the client that some of its requests have been received by the server and are still not rejected. The client should continue to send the remainder of the request, or ignore the response if the request has been completed. The server must send a final response to the client after the request is complete.

101 Switching protocols

The server has understood the client's request and will notify the client via a Upgrade message header that a different protocol is being used to complete the request. After the last empty line of the response is sent, the server switches to those protocols defined in the Upgrade message header.
Similar measures should be taken only when switching to a new protocol is more beneficial. For example, switching to a new HTTP version is more advantageous than an older version, or switching to a real-time, synchronized protocol to deliver resources that exploit this type of feature.

102 Processing

The status code that is extended by WebDAV (RFC 2518), on behalf of processing, will continue to execute.

2XX success

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

OK

The request was successful, and the desired response header or data body will be returned with this response.

201 Created

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

202 Accepted

The server has accepted the request but has not yet processed it. As it may be rejected, the request may or may not be executed at the end. In the case of asynchronous operation, there is no more convenient way to send this status code.
The purpose of a response that returns a 202 status code is to allow the server to accept requests from other processes, such as a batch-based operation that executes only once a day, without having the client remain connected to the server until the batch operation is complete. Responses that accept requests for processing and return a 202 status code should include in the returned entity some information indicating the processing of the current state, as well as pointers to processing status monitors or state predictions so that the user can estimate whether the operation has completed.

203 non-authoritative Information

The server has successfully processed the request, but the returned entity header meta-information is not a valid set on the original server, but a copy from a local or a third party. The current information may be a subset or a superset of the original version. For example, metadata that contains resources may cause the original server to know the meta information is super. It is not necessary to use this status code, and it is appropriate only if the response does not use this status code to return a number of OK.

204 No Content

The server successfully processed the request, but did not need to return any entity content, and wanted to return the updated meta information. The response may return new or updated meta information in the form of an entity header. If the header information exists, it should be echoed with the requested variable.
If the client is a browser, then the user's browser should keep the page that sent the request without any changes in the document view, even if the new or updated meta information by specification should be applied to the document in the user's browser's active view.
Because the 204 response is forbidden to contain any message bodies, it always ends with the first empty line after the message header.

205 Reset Content

The server successfully processed the request and did not return any content. However, unlike the 204 response, a response that returns this status code requires the requestor to reset the document view. The response is primarily used to accept user input and immediately resets the form so that the user can easily start another input.
As with the 204 response, the response is also suppressed to contain any message bodies and ends with the first empty line after the message header.

206 Partial Content

The server has successfully processed a partial GET request. HTTP download tools such as FlashGet or Thunderbolt are used to implement a breakpoint continuation or to decompose a large document into multiple download segments for download at the same time.
The request must contain the range header information to indicate the scope of content that the client expects, and may contain if-range to be used 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, and if Content-type is a multi-segment download for multipart/byteranges, each multipart segment should contain Content-range Fields are used to indicate the content scope of this paragraph. If the response contains Content-length, then its value must match the true number of bytes of the content range it returns.
* Date
* ETag and/or content-location, if the same request should return a 200 response.
* Expires, Cache-control, and/or Vary, if the value may be different than the value of the other response of the same variable as before.
If this response request uses If-range strong cache authentication, then this response should not contain other entity headers, and if the request for this response uses If-range weak cache authentication, then this response prohibits the inclusion of other entity headers, which 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 be returned in the 200 response.
If the ETag or last-modified header does not match exactly, the client cache should prevent the content returned by the 206 response from being combined with any previously cached content.
Any cache that does not support Range and Content-range headers disables caching of 206 of the responses returned.

207 Multi-Status

The status code that is extended by WebDAV (RFC 2518), which represents the following message body, will be an XML message and may contain a series of independent response codes, depending on the number of previous child requests.

3xx redirection

This type of status code represents the need for the client to take further action to complete the request. Typically, these status codes are used for redirection, and subsequent request addresses (redirected targets) are indicated in the location domain of the response.
The user's browser can automatically submit required subsequent requests without user intervention, when and only if the method used by subsequent requests is GET or HEAD. The client should automatically monitor for Infinite loop redirection (for example: A->a, or A->b->c->a), as this can result in a large amount of unnecessary resource consumption by the server and the client. The browser should not automatically access more than 5 redirects, as recommended by the Http/1.0 Edition specification.

Multiple Choices

The requested resource has a range of available feedback information, each with its own specific address and browser-driven negotiation information. The user or browser is able to choose a preferred address to redirect itself.
Unless this is a HEAD request, the response should include an entity with a list of resource attributes and addresses so that the user or browser can choose the most appropriate redirect address. The format of this entity is determined by the format defined by Content-type. The browser may automatically make the most appropriate choice based on the format of the response and the ability of the browser itself. Of course, the RFC 2616 specification does not specify how such an automatic selection should proceed.
If the server itself already has the preferred feedback option, the URI of the feedback should be indicated in the location, which the browser may use as the address for automatic redirection. In addition, this response is cacheable unless otherwise specified.

301 Moved Permanently

The requested resource has been permanently moved to a new location, and any future references to this resource should use one of several URIs returned by this response. If possible, clients that have link editing capabilities should automatically modify the requested address to the address returned from the server. Unless otherwise specified, the response is cacheable.
The new permanent URI should be returned in the location domain of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a short description.
If this is not a GET or HEAD request, the browser disables automatic redirection unless the user confirms it, because the requested condition may vary.
Note: For some browsers that use the http/1.0 protocol, when they send a POST request that gets a 301 response, the next redirect request becomes a Get method.

302 Found

The requested resource is now temporarily responding to requests from different URIs. Because such redirects are temporary, the client should continue to send subsequent requests to the original address. This response is cacheable only if specified in Cache-control or expires.
The new temporary URI should be returned in the location domain of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a short description.
If this is not a GET or HEAD request, then the browser disables automatic redirection unless the user confirms it, because the requested condition may vary.
Note: Although the RFC 1945 and RFC 2068 specifications do not allow the client to change the method of the request during redirection, many existing browsers treat the 302 response as a 303 response, and use GET to access the URI specified in the location, ignoring the method originally requested. Status Codes 303 and 307 are added to clarify how the server expects the client to react.

303 See other

The response to the current request can be found on another URI, and the client should access that resource in a GET way. This method exists primarily to allow the output of the POST request that is activated by the script to redirect to a new resource. This new URI is not an alternative reference to the original resource. Meanwhile, a 303 response is forbidden to be cached. Of course, a second request (redirect) may be cached.
The new URI should be returned in the location domain of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a short description.
Note: Many http/1.1 versions of previous browsers do not correctly understand the 303 status. If you need to consider the interaction with these browsers, the 302 status code should be competent, because most browsers handle 302 response in the way that the above specification requires the client to handle the 303 response should be done.

304 Not Modified

The server should return this status code if the client sends a conditional GET request and the request has been allowed, and the contents of the document (since the last time it was accessed or based on the requested condition) have not changed. The 304 response suppresses the inclusion of the message body, so it always ends with the first empty line after the message header.
The response must contain the following header information:
* Date, unless the server does not have a clock. If a server without a clock follows these rules, then the proxy server and the client can add the Date field to the received response header (as specified in RFC 2068), and the caching mechanism will work correctly.
* ETag and/or content-location, if the same request should return a 200 response.
* Expires, Cache-control, and/or Vary, if the value may be different than the value of the other response of the same variable as before.
If this response request uses strong cache authentication, then this response should not contain other entity headers, otherwise (for example, a conditional GET request uses weak cache validation), this response prohibits the inclusion of other entity headers, which avoids inconsistencies between the cached entity content and the updated entity header information.
If a 304 response indicates that the current entity does not have a cache, the caching system must ignore the response and repeat the request with no restrictions.
If you receive a 304 response that requires a cache entry to be updated, the cache system must update the entire entry to reflect all the values of the fields that were updated in the response.

305 Use Proxy

The requested resource must be accessed through the specified proxy. The URI information for the specified proxy is given in the location domain, and the recipient needs to send a separate request repeatedly to access the resource. Only the original server can establish a 305 response.
Note: There is no explicit 305 response in RFC 2068 to redirect a single request and can only be established by the original server. Ignoring these restrictions can lead to serious security consequences.

306 Switch Proxy

In the latest version of the specification, the 306 status code is no longer in use.

307 Temporary Redirect

The requested resource is now temporarily responding to requests from different URIs. Because such redirects are temporary, the client should continue to send subsequent requests to the original address. This response is cacheable only if specified in Cache-control or expires.
The new temporary URI should be returned in the location domain of the response. Unless this is a HEAD request, the response entity should contain a hyperlink to the new URI and a short description. Because some browsers do not recognize the 307 response, you need to add the necessary information above so that users can understand and make access requests to the new URI.
If this is not a GET or HEAD request, then the browser disables automatic redirection unless the user confirms it, because the requested condition may vary.

4XX Request Error

This type of status code indicates that the client may appear to have an error that prevents the server from processing. Unless the response is a HEAD request, the server should return an entity that interprets the current error condition, and whether this is a temporary or permanent condition. These status codes apply to any request method. The browser should display to the user any entity content contained in such an error response.
If the client is transmitting data when an error occurs, the server implementation using TCP should carefully ensure that the client has received a packet containing the error message before shutting down the connection between the client and the server. If the client continues to send data to the server after receiving the error message, the server's TCP stack sends a reset packet to the client to clear all unrecognized input buffers for that client so that the data is not read by the application on the server and interferes with the latter.

Request

The current request cannot be understood by the server because it contains a syntax error. Unless modified, the client should not submit the request repeatedly.

401 Unauthorized

The current request requires user authentication. The response must contain a Www-authenticate information header for the requested resource to ask for user information. The client can repeatedly submit a request that contains the appropriate Authorization header information. If the current request already contains the Authorization certificate, the 401 response indicates that the certificate has been rejected by the server authentication. If the 401 response contains the same authentication query as the previous response, and the browser has tried at least one validation, the browser should show the user the entity information contained in the response, because the entity information may contain related diagnostic information. See RFC 2617.

402 Payment Required

This status code is reserved for possible future requirements.

403 Forbidden

The server has understood the request, but refuses to execute it. Unlike the 401 response, authentication does not provide any help, and the request should not be repeated. If this is not a HEAD request, and the server wants to be able to explain why the request cannot be executed, then the reason for the rejection should be described within the entity. Of course the server can also return a 404 response if it does not want the client to get any information.

404 Not Found

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

405 Method not allowed

The request method specified in the request line cannot be used to request the appropriate resource. The response must return an allow header to indicate a list of request methods that the current resource can accept.
Because the Put,delete method writes to resources on the server, most Web servers do not support or do not allow the above request method under the default configuration, and 405 errors are returned for such requests.

406 Not acceptable

The content attribute of the requested resource could not satisfy the criteria in the request header, so the response entity could not be generated.
Unless this is a HEAD request, the response should return an entity that contains the most appropriate entity attributes and address lists that the user or browser can choose from. The format of the entity is determined by the media type defined in the Content-type header. The browser can make the best choice based on its format and ability. However, the specification does not define any criteria for making such automatic selections.

407 Proxy Authentication Required

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

408 Request Timeout

The request timed out. The client does not complete a request in the time the server is waiting to be sent. The client can submit the request again at any time without making any changes.

409 Conflict

The request could not be completed because there was a conflict between the current state of the requested resource and the request. This code is only allowed to be used in situations where the user is considered to be able to resolve the conflict and will resubmit the 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 a version-checking environment, where the version information that accompanies a PUT-submitted modification request for a specific resource conflicts with one of the previous (third-party) requests, the server should return a 409 error informing the user that the request could not be completed. At this point, it is likely that the response entity will contain a diff comparison between the two conflicting versions, so that the user can resubmit the new version after merging.

410 Gone

The requested resource is no longer available on the server, and there are no known forwarding addresses. Such a situation should be considered permanent. If possible, a client with link editing should remove all references to this address after obtaining the user's permission. If the server does not know or is unsure whether the condition is permanent, then the 404 status Code should be used. Unless otherwise noted, the response is cacheable.
410 The purpose of the response is primarily to help the site administrator maintain the site, informing the user that the resource is no longer available, and that the server owner wants all remote connections that point to the resource to be deleted. Such events are common in time-limited and value-added services. Similarly, a 410 response is used to notify the client that a resource that was originally owned by a person is 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 how long it will take to keep this tag.

411 Length Required

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

412 Precondition Failed

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

413 Request Entity Too Large

The server refuses to process the current request because the size of the entity data submitted by the request exceeds the scope that the server is willing or able to handle. In this case, the server can close the connection to prevent the client from continuing to send this request.
If this condition is temporary, the server should return a retry-after response header to tell the client how much time it can retry.

414 Request-uri Too Long

The requested URI length exceeds the length that the server can interpret, so the server refuses to service the request. This is rare, and the usual situations include:
* A form submission that should use the POST method becomes a GET method that causes the query string to be too long.
* REDIRECT uri "black Hole", for example, each redirect takes the old Uri as part of the new URI, resulting in a long URI after several redirects.
* The client is trying to exploit a security vulnerability in some servers to attack the server. This type of server uses a fixed-length buffer to read or manipulate the requested URI, and when the GET parameter exceeds a certain value, a buffer overflow may result, resulting in arbitrary code being executed {{cite web|title=http GET buffer Overflow vulnerability is present |url=http:// Www.xfocus.net/vuls/200208/2839.html}}. A server that does not have such a vulnerability should return a 414 status code.

415 Unsupported Media Type

For the currently requested method and the requested resource, the entity submitted in the request is not a supported format in the server and therefore the request is rejected.

416 Requested Range not satisfiable

If a range request header is included in the request, and any data range specified in range does not coincide with the current resource's available range, and the request does not have a If-range request header defined, the server should return a 416 status code.
If range uses a byte range, this is the case where the first byte position of all data ranges specified by the request exceeds the current resource's length. The server should also include a Content-range entity header to indicate the length of the current resource while returning a 416 status code. This response is also forbidden to use 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 the server is a proxy server, and it has obvious evidence that the contents of the Expect are not satisfied on the next node of the current route.

421 There is too many connections from your Internet address

The number of connections from the current client's IP address to the server exceeds the maximum range of server licenses. Typically, 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 well-formed, but cannot be responded to because of a semantic error. (RFC 4918 WebDAV)

423 Locked

The current resource is locked. (RFC 4918 WebDAV)

424 Failed Dependency

The current request failed, such as PROPPATCH, because of an error that occurred in a previous request. (RFC 4918 WebDAV)

425 Unordered Collection

Defined in the WebDAV advanced collections draft, but does not appear in the WebDAV sequence set protocol (RFC 3658).

426 Upgrade Required

The client should switch to tls/1.0. (RFC 2817)

449 Retry With

Extended by Microsoft, the representative request should be retried after the appropriate action has been performed.

5XX Server Error

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

Internal Server Error

The server encountered an unexpected condition that prevented it from completing the processing of the request. Generally speaking, this problem will appear when the server's code is wrong.

501 Not implemented

The server does not support a feature that is required for the current request. When the server does not recognize the requested method and cannot support its request for any resource.

502 Bad Gateway

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

503 Service Unavailable

The server is currently unable to process the request due to temporary server maintenance or overloading. This situation is temporary and will be resumed after a certain period of time. If the delay time can be estimated, then the response can include a retry-after header to indicate the delay time. If this retry-after message is not given, the client should handle it in a manner that handles 500 responses.
Note: The presence of a 503 status code does not mean that the server must use it when it is overloaded. Some servers simply want to deny connections to clients.

504 Gateway Timeout

When a server acting as a gateway or agent attempts to execute a request, it fails to receive a response from the upstream server (the server that the URI identifies, such as HTTP, FTP, LDAP), or the secondary server (such as DNS).
Note: Some proxy servers return 400 or 500 errors in DNS query timeout

505 HTTP Version not supported

The server does not support or refuses to support the HTTP version used in the request. This implies that the server cannot or does not want to use the same version as the client. The response should contain an entity that describes why the version is not supported and which protocols the server supports.

506 Variant Also negotiates

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

507 Insufficient Storage

The server cannot store the content necessary to complete the request. The situation is considered to be temporary. WebDAV (RFC 4918)

509 Bandwidth Limit exceeded

The server reached the bandwidth limit. This is not an official status code, but is still widely used.

510 Not Extended

The policies needed to get resources are not met. (RFC 2774)

Parsing HTTP (HttpURLConnection getresponsecode)