HTTP status code parsing and http status Parsing

HTTP status code parsing and http status Parsing

Reference: http://tool.oschina.net/commons? Type = 5

Status Code	Description
100	The client should continue sending requests. 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 remaining part 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 complete.
101	The server has understood the client request and will use the Upgrade message header to notify the client to use different protocols to complete the request. After sending the final blank line of the response, the server will switch to the protocols defined in the Upgrade message header. Similar measures should be taken only when switching to a new protocol is more advantageous. For example, switching to a new HTTP Version is more advantageous than the old version, or switching to a real-time and synchronous protocol to transmit resources that utilize such features.
102	The Status Code extended by WebDAV (RFC 2518) indicates that the processing will continue.
200	The request is successful, and the desired response header or data body will be returned with this response.
201	The request has been implemented, and a new resource has been created based on the request requirements, and its URI has been returned with the Location header information. If the required resources cannot be created in a timely manner, the system should return '202 accepted '.
202	A 202 status code response is returned to allow the server to accept requests from other processes (for example, a batch-based operation that is executed only once a day ), the client does not have to be connected to the server until all batch operations are completed. Responses that accept request processing and return status code 202 should include some information indicating the processing of the current status in the returned entity, as well as a pointer to the processing status monitor or status prediction, this allows you to determine whether the operation has been completed.
203	The server has successfully processed the request, but the returned object header metadata 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 superset of the original version. For example, metadata containing resources may cause the original server to know the metadata super. This status code is not required, and it is appropriate only when the response does not use this status code and 200 OK is returned.
204	The server successfully processes the request, but does not need to return any entity content and wants to return the updated metadata. The response may return new or updated metadata in the form of an object header. If such header information exists, it should echo the requested variable. If the client is a browser, 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 metadata according to the specifications should be applied to the documents in the user browser activity view. Because the 204 response is forbidden to contain any message body, it always ends with the first blank line after the message header.
205	The server successfully processes the request and does not return any content. However, unlike the 204 response, the response that returns this status code requires the requester to reset the document view. This response is mainly used to reset the form immediately after receiving user input, so that the user can easily start another input. Like the 204 response, the response is also forbidden to contain any message body and ends with the first blank line after the message header.
206	The server has successfully processed some GET requests. HTTP download tools similar to FlashGet or thunder use this type of response to achieve resumable upload or split a large document into multiple download segments for simultaneous download. The request must contain the Range header to indicate the content Range that the client wants and may contain If-Range as the request condition. The response must contain the following header fields: Content-Range, which indicates the Range of Content returned in this response. If the Content-Type is multipart/byteranges, each multipart segment should contain the Content-Range field to indicate the Content Range of this segment. If the response contains Content-Length, its value must match the actual number of bytes in the returned Content range. Date ETag and/or Content-Location. If the same request is sent, 200 response should be returned. Expires, Cache-Control, and/or Vary, if the value may be different from the value corresponding to other responses of the same variable. If the response request uses the If-Range strong cache verification, the response should not contain other entity headers. If the Response Request uses the If-Range weak cache verification, this response prohibits the inclusion of other object headers. This prevents inconsistency between the cached object content and the updated object 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 header cannot be exactly matched, the client cache should prohibit the combination of the 206 response returned content and any previously cached content. Any cache that does not support the Range and Content-Range headers prohibits the caching of the Content returned by the 206 response.
207	The Status Code extended by WebDAV (RFC 2518) indicates that the subsequent message body is an XML message and may contain a series of independent response codes based on the number of previous subrequests.
300	The requested resource has a series of optional feedback information, each of which has its own specific address and browser-driven deliberation information. Users or browsers can select a preferred address for redirection. Unless this is a HEAD request, the response should include an entity in the list of resource features and addresses, so that the user or browser can select the most appropriate redirection address from it. The format of this object 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 to perform such automatic selection. If the server already has the preferred feedback option, you should specify the URI of the feedback in Location. The browser may use this Location value as the automatically redirected address. In addition, this response can be cached unless otherwise specified.
301	The requested resource has been permanently moved to a new location. In the future, any reference to this resource should use one of the several Uris returned in this response. If possible, clients with the link editing function should automatically change the requested address to the address returned from the server. This response can be cached unless otherwise specified. The new permanent URI should be returned in the response Location domain. Unless this is a HEAD request, the response entity should contain hyperlinks and brief descriptions pointing 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 request conditions may change. Note: For Some browsers that use the HTTP/1.0 protocol, when the POST requests they send receive a 301 response, the next redirect request will become the GET method.
302	The requested resource now temporarily responds to the request from different Uris. As such redirection is temporary, the client should continue to send future requests to the original address. This response can be cached only when Cache-Control or Expires is specified. The new temporary URI should be returned in the response Location domain. Unless this is a HEAD request, the response entity should contain hyperlinks and brief descriptions pointing 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 request conditions may change. Note: Although RFC 1945 and RFC 2068 do not allow the client to change the request method during redirection, many existing browsers regard the 302 response as a 303 response, in addition, the GET method is used to access the URI specified in Location, regardless of the original request method. Status Codes 303 and 307 are added to specify the response that the server expects from the client.
303	The response corresponding to the current request can be found on another URI, and the client should use the GET method to access that resource. This method is mainly used 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, 303 of responses are forbidden from being cached. Of course, the second request (redirection) may be cached. The new URI should be returned in the response Location domain. Unless this is a HEAD request, the response entity should contain hyperlinks and brief descriptions pointing to the new URI. Note: Many browsers earlier than HTTP/1.1 cannot correctly understand the 303 status. If you need to consider interaction with these browsers, the 302 status code should be competent, because most browsers handle the 302 response in exactly the way that the above specifications require the client to handle the 303 response.
304	If the client sends a GET request with a condition and the request has been allowed, and the content of the document (since the last access or according to the condition of the request) has not changed, the server should return this status code. 304 the response is forbidden to contain the message body. Therefore, it always ends with the first blank line after the message header. The response must contain the following header information: Date, unless the server has no clock. If a server without a clock complies with these rules, the proxy server and the client can add the Date field to the received Response Header (as specified in RFC 2068 ), the cache mechanism will work normally. ETag and/or Content-Location. If the same request should have returned a 200 response. Expires, Cache-Control, and/or Vary, if the value may be different from the value corresponding to other responses of the same variable. If this Response Request uses strong cache verification, this response should not contain other entity headers; otherwise (for example, a conditional GET request uses weak cache verification ), this response prohibits the inclusion of other object headers. This avoids inconsistency between cached object content and updated object header information. If a 304 response indicates that an object is not cached, the cache system must ignore the response and repeatedly send requests that do not contain restrictions. If a 304 response is received to update a cache entry, the cache system must update the entire entry to reflect the values of all the fields updated in the response.
305	The requested resource can be accessed only through the specified proxy. The specified proxy URI is provided in the Location field. The receiver must send a separate request to access the corresponding resource. Only the original server can establish a 305 response. Note: RFC 2068 does not specify that the 305 response is to redirect a separate request and can only be created by the original server. Ignoring these limits may cause serious security consequences.
306	In the latest specification, status code 306 is no longer in use.
307	The requested resource now temporarily responds to the request from different Uris. As such redirection is temporary, the client should continue to send future requests to the original address. This response can be cached only when Cache-Control or Expires is specified. The new temporary URI should be returned in the response Location domain. Unless this is a HEAD request, the response entity should contain hyperlinks and brief descriptions pointing to the new URI. Because some browsers cannot recognize 307 responses, you need to add the necessary information so that users can understand and send access requests to new Uris. If this is not a GET or HEAD request, the browser prohibits automatic redirection unless it is confirmed by the user because the request conditions may change.
400	1. The syntax is incorrect. The current request cannot be understood by the server. The client should not submit this request again unless it is modified. 2. The request parameters are incorrect.
401	The current request requires user authentication. The response must contain a WWW-Authenticate header for the requested resource to ask for user information. The client can submit a request that contains the appropriate Authorization header information. If the current request already contains the Authorization certificate, then the 401 response indicates that the server authentication has rejected those certificates. If the 401 response contains the same authentication request as the previous response, and the browser has tried verification at least once, the browser should display the entity information contained in the response to the user, this entity information may contain diagnostic information. See RFC 2617.
402	This status code is reserved for future potential needs.
403	The server has understood the request but refused to execute it. Different from 401 responses, authentication cannot provide any help and the request should not be submitted repeatedly. If this is not a HEAD request and the server wants to clarify why the request cannot be executed, the reason for rejection should be described in the entity. Of course, the server can also return a 404 response, if it does not want the client to obtain any information.
404	Request failed. The requested resource is 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 inform the old resource that it is permanently unavailable due to some internal configuration mechanism problems, and there is no jump address. 404 this status code is widely used when the server does not want to reveal why the request is rejected or no other suitable response is available.
405	The request method specified in the request line cannot be used to request resources. The response must return an Allow header to indicate a list of request methods that the current resource can accept. The PUT and DELETE Methods write resources on the server. Therefore, most Web servers do not support the PUT and DELETE methods, or the above request methods are not allowed in the default configuration, for such requests, error 405 is returned.
406	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 object that contains the entity that allows the user or the browser to select the most appropriate entity feature and address list. The format of an object is determined by the media Type defined in the Content-Type header. The browser can make the best choice based on the format and its own capabilities. However, the specification does not define any criteria for making such automatic choices.
407	Similar to the 401 response, the client must perform authentication 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. The client did not complete sending a request within the waiting time of the server. The client can submit this request again at any time without any changes.
409	The request cannot be completed because of a conflict with the current status of the requested resource. This code can only be used in this case: the user is considered to be able to resolve the conflict, and a new request will be submitted again. The response should contain sufficient information for the user to find the source of the conflict. A conflict usually occurs in the processing of PUT requests. For example, in a version check environment, the version information contained in a PUT request to modify a specific resource conflicts with a previous (third-party) request, in this case, the server should return a 409 error, notifying the user that the request cannot be completed. In this case, the response entity may include a comparison between two conflicting versions, so that you can resubmit the new versions after merging.
410	The requested resource is no longer available on the server and there is no known forwarding address. Such a situation should be considered permanent. If possible, clients with the link editing function should delete all references pointing to this address after obtaining 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. This response can be cached unless otherwise specified. 410 The purpose of the response is to help the website administrator maintain the website and notify the user that the resource is no longer available, and the server owner wants all remote connections pointing to the resource to be deleted. Such events are common in time-limited and value-added services. Similarly, the 410 response is used to notify the client on the current server site that resources belonging to a certain person are no longer available. Of course, whether you need to mark all permanently unavailable resources as '100 gone' and how long it will take to keep it depends entirely on the server owner.
412	The server fails to meet one or more of the prerequisites in the request header field. This status code allows the client to set the prerequisites in the requested metadata (request header field data) when obtaining resources, this prevents the request method from being applied to resources other than the desired content.
413	The server rejects the current request because the size of the physical data submitted by the request exceeds the scope that the server is willing to or can handle. In this case, the server can close the connection to prevent the client from sending this request. If this condition is temporary, the server should return a Retry-After response header to tell the client how long it will take to Retry.
414	The length of the request URI exceeds the length that the server can interpret. Therefore, the server rejects the request. This is rare. The common situations include: the form submission that should have used the POST method is changed to the GET method, resulting in the Query String being too long. Redirection URI "black hole". For example, the old URI is used as a part of the new URI each time, resulting in a long URI after several redirection. The client is attempting to use security vulnerabilities on some servers to attack the server. These servers use fixed-length buffer read or operation request Uris. When the GET parameter exceeds a certain value, a buffer overflow may occur, resulting in arbitrary code execution [1]. Servers that do not have such vulnerabilities should return status code 414.
415	For the current request method and requested resources, the entity submitted in the request is not in the format supported by the server, so the request is rejected.
416	If the request contains a Range request header, and any data Range specified in the Range does not overlap with the available Range of the current resource, and the request does not define the If-Range request header, the server should return the 416 status code. If Range uses a byte Range, this means that the first byte location of all data ranges specified by the request exceeds the length of the current resource. The server should also contain a Content-Range object header while returning the 416 status code to specify the length of the current resource. This response is also forbidden to use multipart/byteranges as its Content-Type.
417	The expected content specified in the request header cannot be met by the server, or the server is a proxy server, which has obvious evidence that it is on the next node of the current route, the content of CT cannot be satisfied.
421	The number of connections from the IP address of the current client to the server exceeds the maximum permitted range of the server. Generally, the IP address here refers to the client address (such as the user's gateway or proxy server address) seen on the server ). In this case, the number of connections may involve more than one end user.
422	The number of connections from the IP address of the current client to the server exceeds the maximum permitted range of the server. Generally, the IP address here refers to the client address (such as the user's gateway or proxy server address) seen on the server ). In this case, the number of connections may involve more than one end user.
422	The request format is correct, but the request cannot be responded due to semantic errors. (RFC 4918 WebDAV) 423 the current Locked 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 draft WebDav Advanced Collections, but not found in the WebDAV sequence set protocol (RFC 3658.
426	The client should switch to TLS/1.0. (RFC 2817)
449	By Microsoft extension, requests should be retried after appropriate operations are performed.
500	The server encountered an unexpected situation, causing it to fail to process the request. Generally, this problem occurs when the program code on the server fails.
501	The server does not support a function required by the current request. When the server cannot identify the Request Method and cannot support its requests to any resource.
502	When a gateway or proxy server tries to execute a request, it receives an invalid response from the upstream server.
503	The server cannot process requests because of temporary server maintenance or overload. This situation is temporary and will be restored after a period of time. If you can predict the delay time, the response can contain a Retry-After header to indicate the delay time. If this Retry-After information is not provided, the client should process it in the form of 500 response. Note: The existence of status code 503 does not mean that the server must use it during overload. Some servers only want to reject client connections.
504	When a server that works as a gateway or proxy attempts to execute a request, it fails to promptly access the upstream server (the server identified by the URI, such as HTTP, FTP, LDAP) or the secondary server (such as DNS) receive the response. Note: Some proxy servers will return error 400 or 500 when DNS query times out.
505	The server does not support or rejects 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 what protocols the server supports.
506	Extended by transparent content negotiation protocol (RFC 2295), it indicates that the server has an internal configuration error: the requested negotiated variable resource is configured to be used in transparent content negotiation, therefore, it is not a proper focus in a negotiation process.
507	The server cannot store the content required to complete the request. This situation is considered temporary. WebDAV (RFC 4918)
509	The server reaches the bandwidth limit. This is not an official status code, but it is still widely used.
510	The policies required for obtaining resources are not met. (RFC 2774)