Front-end Common status code HTTP status code

HTTP status code
 edit
HTTP Status Code (HTTP Status Code) is a 3-digit code used to indicate the HTTP response status of the web server. It is defined by the RFC 2616 specification and has been extended by RFC 2518, RFC 2817, RFC 2295, RFC 2774, RFC 4918 and other specifications.
 
Chinese name
HTTP status code
Foreign name
HTTP Status Code
Normative definition
RFC 2616
Message side
1 prefix, 2 prefix, 3 prefix
table of Contents
1 Message (1 prefix)
? 100 Continue
? 101 Switching Protocols
? 102 Processing
2 Success (2 prefix)
? 200 OK
? 201 Created
? 202 Accepted
? 203 Non-Authoritative Information
? 204 No Content
? 205 Reset Content
? 206 Partial Content
? 207 Multi-Status
3 Redirect (3 prefix)
? 300 Multiple Choices
? 301 Moved Permanently
? 302 Move temporarily
? 303 See Other
? 304 Not Modified
? 305 Use Proxy
? 306 Switch Proxy
? 307 Temporary Redirect
4 Request error (4 prefix)
? 400 Bad Request
? 401 Unauthorized
? 402 Payment Required
? 403 Forbidden
? 404 Not Found
? 405 Method Not Allowed
? 406 Not Acceptable
? 407 Proxy Authentication Required
? 408 Request Timeout
? 409 Conflict
? 410 Gone
? 411 Length Required
? 412 Precondition Failed
? 413 Request Entity Too Large
? 414 Request-URI Too Long
? 415 Unsupported Media Type
? 416 Requested Range Not Satisfiable
? 417 Expectation Failed
? 422 Unprocessable Entity
? 423 Locked
? 424 Failed Dependency
? 425 Unordered Collection
? 426 Upgrade Required
? 449 Retry With
5 Server error (5, 6 prefix)
? 500 Internal Server Error
? 501 Not Implemented
? 502 Bad Gateway
? 503 Service Unavailable
? 504 Gateway Timeout
? 505 HTTP Version Not Supported
? 506 Variant Also Negotiates
? 507 Insufficient Storage
? 509 Bandwidth Limit Exceeded
? 510 Not Extended
? 600 Unparseable Response Headers
Message (1 prefix)
edit
This type of status code indicates that the request has been accepted and needs to continue processing. This type of response is a temporary response, only contains the status line and some optional response header information, and ends with a blank line. Since there is no 1xx status code defined in the HTTP / 1.0 protocol, unless under certain experimental conditions, the server prohibits sending 1xx responses to such clients.
100 Continue
The client should continue to send requests. This temporary response is used to notify the client that part of its request has been received by the server and has not been rejected. The client should continue to send the rest of the request, or if the request has been completed, ignore this response. 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 header.
Similar measures should only be taken when switching new protocols is more beneficial. For example, switching to the new HTTP version is more advantageous than the old version, or switching to a real-time and synchronous protocol to deliver resources that utilize such features.
102 Processing
The status code extended by WebDAV (RFC 2518) represents that the processing will be continued.
Success (2 word prefix)
edit
This type of status code indicates that the request has been successfully received, understood, and accepted by the server [1].
200 OK
The request has been successful, and the response header or data body desired by the request will be returned with this response.
201 Created
The request has been fulfilled, and a new resource has been created according to the needs of the request, and its URI has been returned with the Location header. If the required resources cannot be established in time, it should return ‘202 Accepted’.
202 Accepted
The server has accepted the request, but has not yet processed it. Just as it may be rejected, eventually the request may or may not be executed. In the case of asynchronous operation, there is no more convenient way than sending this status code.
The purpose of the response that returns the 202 status code is to allow the server to accept requests from other processes (such as a batch-based operation that is only performed once a day) without having to keep the client connected to the server until the batch operation is completed. The response that accepts the request processing and returns a 202 status code should include some information indicating the current status of the processing and a pointer to the processing status monitor or status prediction in the returned entity 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 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 metadata. It is not necessary to use this status code, 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 does not need to return any entity content, and hopes to return the updated meta information. The response may return new or updated meta information in the form of an entity header. If there is such header information, it should correspond to 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 meta information should be applied to the user ’s browser activities according to the specifications The document in view.
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 that returns this status code requires the requester to reset the document view. This response is mainly used to reset the form immediately after accepting user input so that the user can easily start another input.
As with the 204 response, this 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 resumes or break up a large document into multiple download segments for simultaneous download.
The request must include the Range header information to indicate the range of content the client wishes to obtain, and may include If-Range as the request condition.
The response must contain the following header fields:
Content-Range is used to indicate the range of content returned in this response; if it is a multi-segment download with Content-Type multipart / byteranges, then each multipart segment should contain the Content-Range field to indicate the content range of this segment . If the response contains Content-Length, then 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 a 200 response.
Expires, Cache-Control, and / or Vary, if its value may be different from the corresponding value of other responses of the same variable before.
If this response request uses If-Range strong cache verification, then this response should not include other entity headers; if this response request uses If-Range weak cache verification, then this response must not include other entity headers; this avoids Inconsistencies between cached entity content and 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 cannot match exactly, the client cache should prohibit combining the content returned by the 206 response with any previously cached content.
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 sub-requests.
Redirect (3 word header)
edit
This type of status code means that the client needs to take further action to complete the request. Generally, these status codes are used for redirection, and the subsequent request address (redirection target) is indicated in the Location field of this response.
If and only if the method used for the subsequent request is GET or HEAD, the user browser can automatically submit the required subsequent request without user intervention. The client should automatically monitor infinite loop redirection (for example: A-> A, or A-> B-> C-> A), because this will cause a lot of unnecessary resource consumption by the server and the client. As recommended by the HTTP / 1.0 specification, browsers should not automatically access redirects more than 5 times.
300 Multiple Choices
The requested resource has a series of optional feedback information, each with its own specific address and browser-driven consultation information. The user or browser can choose a preferred address for redirection.
Unless this is a HEAD request, the response should include an entity with a list of resource characteristics 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 browser's own capabilities. Of course, the RFC 2616 specification does not specify how such automatic selection should proceed.
If the server itself already has a preferred feedback option, then the Location should indicate the URI of the feedback; the browser may use this Location value as the address for automatic redirection. In addition, unless otherwise specified, this response is also cacheable.
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 the several URIs returned by this response. If possible, the client with the link editing function should automatically modify the requested address to the address returned from the server. Unless otherwise specified, this response is also cacheable.
The new permanent URI should be returned in the Location field of the response. Unless this is a HEAD request, the 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 prohibits automatic redirection unless it is confirmed by the user, because the conditions of the request may change accordingly.
Note: For some browsers that use the HTTP / 1.0 protocol, when the POST request they send gets a 301 response, the subsequent redirect request will become a GET method.
302 Move temporarily
The requested resource temporarily responds to the request from a different URI. Since such redirection is 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.
Mentioned above.
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 accordingly.
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 Locat
The URI specified in ion, regardless of the method originally requested. Status codes 303 and 307 were added to clarify how the server expects the client to respond.
303 See Other
The response to the current request can be found on another URI, and the client should access that resource using GET. This method exists mainly to allow redirection of POST request output activated by the script 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.
Note: Many browsers prior to HTTP / 1.1 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 the 302 response exactly the way the above specifications require the client to handle the 303 response.
304 Not Modified
If the client sends a conditional GET request and the request has been allowed, but the content of the document (since the last access or according to the conditions of the request) has not changed, the server should return this status code. The 304 response is prohibited from including 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 does not have a clock. If the server without the clock also 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), and the caching 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 its value may be different from the corresponding value of other responses of the same variable before.
If this response request uses strong cache authentication, then this response should not include other entity headers; otherwise (for example, a conditional GET request uses weak cache authentication), this response is prohibited from including other entity headers; this avoids Inconsistency between cached entity content and updated entity header information.
If a 304 response indicates that there is currently no cache for an entity, then the cache system must ignore this response and repeatedly send requests that do not contain restrictions.
If a 304 response is received that requires a certain cache entry to be updated, then the cache system must update the entire entry to reflect the values of all fields that were updated in the response.
305 Use Proxy
The requested resource must be accessed through the designated agent. The Location field will give the URI information of the specified agent. The receiver needs to repeatedly send a separate request to access the corresponding resources through this agent. Only the original server can create a 305 response.
Note: There is no explicit 305 response in RFC 2068 to redirect a single request, and it can only be established by the origin 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 used.
307 Temporary Redirect
The requested resource temporarily responds to the request from a different URI.
The new temporary URI should be returned in the Location field of the response. Unless this is a HEAD request, the responding entity should include a hyperlink to the new URI and a short description. Because some browsers cannot recognize the 307 response, the above necessary information 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 accordingly.
Request error (4 prefix)
edit
This type of status code represents that the client may seem to have an error, which hinders the server's processing. Unless the response is a HEAD request, the server should return an entity that explains the current error condition and whether this is a temporary or permanent condition. These status codes apply to any request method. The browser should show the user any physical content contained in such an error response.
If the client is transmitting data when the error occurs, the server implementation using TCP should carefully ensure that the client has received a data packet containing the error information 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 recognized by the client, so as to avoid the data The application reads and interferes with the latter.
400 Bad Request
1. The semantics is incorrect and the current request cannot be understood by the server. Unless modified, the client should not submit this request repeatedly.
2. The request parameters are incorrect.
401 Unauthorized
The current request requires user authentication. The response must include a WWW-Authenticate header applicable to the requested resource to query user information. The client can repeatedly submit a request with the appropriate Authorization header information. If the current request already contains Authorization certificates, then the 401 response represents that the server has verified that those certificates have been rejected. If the 401 response contains the same authentication query 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 this 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 refused 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 clearly why the request cannot be executed, then the reason for the 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 get any information.
404 Not Found
The request failed and the requested resource was not found on the server. There is no information to 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 has been permanently unavailable due to some internal configuration mechanism problems, and there is no address to jump to. The status code 404 is widely used when the server does not want to reveal why the request was rejected or no other suitable response is available. The most likely cause of this error is that the server does not have this page.
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 to indicate a list of request methods that the current resource can accept.
In view of the PUT, DELETE method will write resources on the server, so most web servers do not support or do not allow the above request method in the default configuration, for such requests will return 405 error.
406 Not Acceptable
The content characteristics of the requested resource cannot meet the conditions in the request header, and thus the response entity cannot be generated.
Unless this is a HEAD request, the response should return an entity that contains a list of attributes and addresses from which the user or browser can choose the most appropriate entity. The format of the entity is determined by the media type defined in the Content-Type header. The browser can make the best choice according to the format and its own capabilities. 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 for identity query. The client can return a Proxy-Authorization header for verification. See RFC 2617.
408 Request Timeout
Request timed out. The client did not complete the sending of a request within the time the server was prepared to wait. The client can submit this request again at any time without making any changes.
409 Conflict
The request could not be completed due to a conflict with the current state of the requested resource. This code can only be used in situations where the user is considered to be able to resolve the conflict and will resubmit a new request. The response should contain enough information for the user to find the source of the conflict.
Conflicts usually occur in the processing of PUT requests. For example, in a version check environment, the version information attached to a specific resource modification request submitted by a PUT conflicts with a previous (third-party) request, then the server should return a 409 error at this time. Inform users that the request could not be completed. At this time, the response entity is likely to contain the difference between the two conflicting versions, so that the user can resubmit the new version after the merge.
410 Gone
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 link editing capabilities should delete all references to this address after obtaining user permission. If the server does not know or cannot determine whether this condition is permanent, then the 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 the server owner hopes that all remote connections to this resource will also be deleted. Such events are common in time-limited, value-added services. Similarly, the 410 response is also used to notify the client that at the current server site, resources originally belonging to a certain individual are no longer available. Of course, whether you need to mark all permanently unavailable resources as ‘410 Gone’ and whether you need to keep this mark for a long time depends entirely on the server owner.
411 Length Required
The server refused to accept the request without defining the Content-Length header. After adding a valid Content-Length header indicating the length of the request message body, the client can submit the request again.
412 Precondition Failed
The server failed to satisfy one or more of the prerequisites given in the header field of the request. This status code allows the client to set prerequisites in the requested meta-information (request header field data) when acquiring resources, in order to prevent the request method from being applied to resources other than the content 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 range that the server is willing or able to process. In this case, the server can close the connection to prevent the client from continuing to send this request.
If the situation is temporary, the server should return a Retry-After response header to inform the client how much time can be tried again.
414 Request-URI Too Long
The length of the requested URI exceeds the length that the server can interpret, so the server refuses to serve the request. This is relatively rare, and the usual conditions include:
Form submission that should have used the POST method became the GET method, which caused the query string (Query String) to be too long.
Redirect URI "black hole", for example, each redirect uses the old URI as part of the new URI, resulting in a long URI after several redirects.
The client is trying to exploit the security holes in some servers to attack the server. This type of server uses a fixed-length buffered read or operation request URI. When the parameter after GET exceeds a certain value, a buffer overflow may occur, causing arbitrary code to be executed [1]. Servers without such vulnerabilities should return a 414 status code.
415 Unsupported Media Type
For the currently requested method and requested resource, the entity submitted in the request is not in a format supported by the server, so the request is rejected.
416 Requested Range Not Satisfiable
If the Range request header is included in the request, 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 length of the current resource. The server should also return a 416 status code while including a Content-Range entity header 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, and it has obvious evidence that the content of Expect cannot be satisfied at the next node of the current route.
421 There are too many connections from your internet address
The number of connections from the current IP address of the client to the server exceeds the maximum range allowed by the server. Generally, the IP address here refers to the client address (such as the user's gateway or proxy server address) seen from the server. In this case, the calculation of the number of connections may involve more than one end user.
422 Unprocessable Entity
The request format is correct, but Unable to respond due to semantic errors. (RFC 4918 WebDAV)
423 Locked
The current resource is locked. (RFC 4918 WebDAV)
424 Failed Dependency
The current request failed due to an error in a previous request, such as PROPPATCH. (RFC 4918 WebDAV)
425 Unordered Collection
It was defined in the WebDav Advanced Collections draft, but did 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 requests that retry should be performed after the appropriate operation is performed.
Server error (5, 6 prefix)
edit
This type of status code indicates that an error or abnormal state occurred during the processing of the request by the server. It may also be that the server realized that the current software and hardware resources could not complete the processing of the request. Unless this is a HEAD request, the server should contain an information entity that explains the current error status and whether the condition is temporary or permanent. The browser should show the user any entities included in the current response.
These status codes apply to any response method.
500 Internal Server Error
The server encountered an unexpected situation that prevented it from completing the request. Generally speaking, this problem occurs when the source code of the server is wrong.
501 Not Implemented
The server does not support a function required by the current request. When the server cannot identify the requested method and cannot support its request for any resources.
502 Bad Gateway
When a server working as a gateway or proxy attempts to execute a request, it receives an invalid response from the upstream server.
503 Service Unavailable
Due to temporary server maintenance or overload, the server is currently unable to process the request. This situation is temporary and will be restored after a period of time. If the delay time can be estimated, the response can include a Retry-After header to indicate the delay time. If this Retry-After message is not given, then the client should process it in a 500 response.
Note: The presence of the 503 status code does not mean that the server must use it when it is overloaded. Some servers simply want to reject the client's connection.
504 Gateway Timeout
When a server working as a gateway or proxy attempts to execute a request, it fails to receive a response from an upstream server (the server identified by the URI, such as HTTP, FTP, LDAP) or a secondary server (such as DNS).
Note: Some proxy servers will return a 400 or 500 error when the DNS query times out
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 will not use the same version as the client. The response should contain an entity describing why the version is not supported and which protocols the server supports.
506 Variant Also Negotiates
Expanded by the "Transparent Content Negotiation Protocol" (RFC 2295), it represents an internal configuration error in the server: the requested negotiation 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 the bandwidth limit. This is not an official status code, but it is still widely used.
510 Not Extended
The strategies required to obtain resources are not unsatisfactory. (RFC 2774)
600 Unparseable Response Headers
The origin does not return the response header, only the entity content
Common front-end status codes http status codes

Tag: resource reference http status code estimate solve config also has sum ges

Original address: http://www.cnblogs.com/izengbin/p/6768541.html