Rfc2616-http1.1-status Code (Status Code Provisions section-translated)

Part of hypertext Transfer Protocol--http/1.1

RFC 2616 Fielding, et al.10 Status Code rule (status code definitions)

This article describes the relevant rules for each status code, including the method to be followed by the corresponding status code and any meta-information required in the response.

10.1 Informational 1XX

The class status code represents a temporary response, consisting only of a status line and an optional head, and ends with a blank line. The class status code does not have a required header field. Since http/1.0 does not define any 1xx status codes, the server cannot send a 1xx response to the http/1.0 client unless under experimental conditions.

Before a regular response is returned, the client must be ready to accept one or more of the possible 1xx responses, even if the client does not require a CONTINUE status message. Unwanted 1xx response states may be ignored by the client.

The agent must forward a 1xx response, even if the proxy and its client's link are closed, or unless the proxy itself requires a 1xx response to be generated. (For a chestnut, the agent adds the "expect:100-continue" field when forwarding the request, so it does not need to forward the corresponding (continue) field).

10.1.1 Continue

The client should continue to send its request. The temporary response is used to notify the client that the initial part of the request has been accepted and has not been rejected by the server. After the request has ended, the server must return a final response. See section 8.2.3 For more detailed information about the status code.

10.1.2 101 Switching Protocol (switching protocols)

The server understands and is willing to follow the client's request by upgrading the Message header field (section 14.42) to modify the application protocol used on the link. The server immediately switches the protocol to the response that contains the Upgrade header field after the empty line terminates the 101 response.

The protocol should only be switched if it is advantageous. For a chestnut, switching to a newer version of HTTP is more advantageous than the older version, and switching to a real-time, synchronous protocol may be more advantageous when passing resources that use these features.

10.2 Successful 2XX

This class status code indicates that the client's request has been successfully received, understood, and accepted.

10.2.1 OK

The request has been successful. The information returned in the response depends on the method used in the request, for example:

Get entities that match the requested resource are returned in the response;

The Entity header field that the head is consistent with the requested resource is returned in the response with no message body (message-body) in response to the returned content;

POST a description or entity that contains the result of the execution;

TRACE contains the entity of the request message received by the Terminal Server.

10.2.2 201 Created (created)

The request has been completed and a new resource has been created. The newly created resource can be referenced by the URI returned in the response entity, and the specified URI referenced by the resource is given in the Location header field. The response should include an entity that contains a list of resource attributes and locations from which the user or user agent can choose the most appropriate one. The format of the entity is specified by the media type in the Content-type header field. The meta-server must generate the appropriate resources before returning a 201 status code. If the execution results cannot be resolved immediately, the server needs to be replaced with a 202 (Accepted) response.

A 201 response may contain an ETag response header field that represents the current value of the entity label for the requested variable you just created, as detailed in section 14.19.

10.2.3 202 Accepted (Received)

The request has been accepted and is being processed, but the processing has not been completed yet. The request may or may not be processed because it may be blocked when dealing with a problem that actually occurs. A status code cannot be resent in an asynchronous operation like this.

202 The response is intentionally non-committal. Its purpose is to allow the server to receive requests from other processes (perhaps a batch processing (batch-oriented) session is performed only once a day), without the need for a user agent to connect to the server until the process is complete. The entity returned using this response should include a description of the current state of the request and an estimate pointing to the status Monitor or when the user can expect that the request has been completed.

10.2.4 203 non-authoritative Information (non-authorized information)

The meta information returned in the entity header is not a final collection available to the meta server, but is copied from a local or third party. The collection that is rendered can be either a subset of the original version or a parent set. For example, a local comment containing information about a resource has the potential to become the parent set of source information known to the Meta server. This response code is only applicable if the response is 200.

10.2.5 204 No content (no contents)

The server has completed the request, but does not need to return the entity principal, and may need to return updated meta information. The response may include the latest or updated source information in the form of the entity header, which, if present, needs to be associated with the requested variable.

If the client is a user agent, it should not be changed from its document view in the requested document. This response is primarily used to allow input actions without causing changes to the active document view of the user agent, although any new or updated meta information should be applied to the document currently in the active view of the user agent.

The 204 response does not need to include a message body, so the first empty line after the header field is always terminated.

10.2.6 205 Reset Content (reset contents)

The server has completed the corresponding request, and the user agent needs to reset the view of the document that caused the request to be sent. This response is primarily intended to allow input through user input, and then clears the entered form so that the user can easily initiate another input operation. The response cannot contain entities.

10.2.7 206 Partial content (partial)

The server has completed obtaining a partial GET request for the resource. The request must contain a Range header field (section 14.35) that specifies the scope of the expected fetch, and may contain a If-range header field (14.27 bars) to make the request dependent on the condition.

The response of the request must contain the following header fields:

-  The response needs to include a Content-range header field that describes the scope, or a multipart/byte range (Multipart/byteranges) that contains the Content-range field for each part.
The Content-type field. If the Content-length header field exists in the response, its value must match the eight-byte value transferred in the body of the message.

      -Date

-ETag and/or content-location if the message header responds to the same request in the form of 200.

-Expires,cache-control, and/or Vary if the field value differs from the value of any response previously sent for the same variant.

If the 206 response is the result of a If-range request that uses strong cache validation (see 13.3.3 for details), the response should not contain other entity headers. If this corresponds to the result of a If-rang request that uses weak cache validation, then the response must not contain other entity headers. This is to prevent an issue in which the cached entity is inconsistent with the updated header field. Otherwise, for those same requests that have returned a 200 response, the response must contain all the entity headers.

If the ETag or last-modified header fields do not match, then the cache must not be able to combine the 206 response with other previously cached content. (see section 13.5.4 for details)

A header field that does not provide range and Content-range must not cache a 206 response.

10.3 Redirect (redirection) 3xx

This type of status code indicates that a further action by the user agent is required in order to complete the request. When and only if the second request is a GET or head request, the required action can be performed by the user agent only, without interacting with the user. The client should detect an infinite redirect loop because such a loop causes each redirect to generate network traffic.

      Note: Previous versions of this specification are recommended to redirect up to five times. Developers should be aware that there may be a fixed limitation on the client side.

10.3.1 300 + options (multiple Choices)

The requested resource matches any one of the proxy resource collections, each with its specified address, and provides the agent-driven (agent-driven)-Related Negotiation information (section 12th) that allows the user or user agent to select a better proxy and redirect the request to this address.

Even for a head request, the response needs to contain an entity, which also has a list of related resource classes and addresses, which allows the user or user agent to select one of the most matching resources as a result. The entity format is determined by the media type specified by the Content-type header field. Depending on the format and ability of the user agent, the most appropriate choice can be performed automatically. However, the specification does not define any criteria for this automatic selection.

If the server has a preferred choice, he should include the URI of the specified resource in the Location field. The user agent may automatically redirect with the Location field value. Unless otherwise noted, this response can be cached.

10.3.2 301 Permanent removal (Moved permanently)

The requested resource has been assigned a new permanent URI, and any future references to that resource should use one of the returned URIs. Clients with linking capabilities should automatically relink references to the request URI (Request-uri) reference to one or more new references returned by the server, if possible.

The new permanent URI needs to be noted in the Location field in the response.

If the request method that receives a 301 status in response to a request is not head or get, then the user agent cannot automatically redirect the request unless the user can confirm the request, as this may change the condition that the request is issued.

Note: When a POST request is automatically redirected after a 301 status code is received, some existing http/1.0 user agents will incorrectly change it to a GET request.
　

10.3.3 302 found (Found)

The requested resource is temporarily stored under a different URI. Because redirects can sometimes be changed, clients should continue to use the request URI (Request-uri) for future requests. The response is cached only when the Cache-control or Expires header field is described.

The temporary URI should be provided by the location field in the response. Unless the request method is head, the responding entity should contain a short hypertext comment with a hyperlink to the new URI.

If the request method that receives a 302 status in response to a request is not head or get, then the user agent cannot automatically redirect the request unless the user can confirm the request, as this may change the condition that the request is issued.

NOTE:RFC 1945 and RFC 2068 specify that clients are not allowed to change methods on redirection requests. However, most existing user-agent implementations treat 302 as a 303 response and perform a get on the Location field value, regardless of the original request method. For those types of reactions that wish to clearly indicate customer expectations
Server, the status Codes 303 and 307 have been added.

10.3.4 303 See also other

The response to the request can be found under a different URI and should be retrieved using the Get method on the cinema. This method is primarily used to allow the output of a POST activation (post-activated) script to redirect the user agent to the selected resource. The new URI is not an alternative reference to the originally requested resource. The 303 response cannot be cached, but the second (or redirect) request for the response may be cached.

Different URIs need to be given in the location field of the response. Unless the request method is head, the responding entity should contain a short hypertext comment with a hyperlink to the new URI.

      Note: Many http/1.1 previous versions of the Protocol do not understand the 303 status. When you need to interoperate with such clients, you can use a 302 status code, because most user agents respond to the 302 status as described here in 3,031.

10.3.5 304 unmodified (not Modified)

If the client performs a conditional GET request and allows access, but the file is not modified, the status code should respond with that status code. A 304 response cannot contain a message body, so it always ends with the first empty line after the header field.

The response must contain the following header fields:

      -Date, unless he is required to be omitted as described in the 14.18.1 section

If a server without clocks follows these rules, and the agent and the client add their own dates to any response that does not receive the server date (as specified in section 14.19 of [RFC 2068]), the cache will run correctly.

      -ETag and/or content-location, if the message header is sent as a 200 response to the same request.

      -Expires, Cache-control, and/or Vary, if the field value may be different than the same variable that was sent in the previous response.

If a conditional GET request uses a strong cache validation (see section 13.3.3 for details), the response cannot include other entity header fields. Otherwise (that is, a conditional GET request uses weak authentication), and the response must not contain other entity headers. This prevents inconsistencies between the cached entities and the updated header fields.

If the 304 response represents an entity that is not currently cached, the cache must ignore the response and re-initiate an unconditional request.

If a cache uses the received 304 response to update a cache entry, the cache must update the entry to reflect any new field values given in the response.

10.3.6 305 using proxies (use proxy)

The requested resource must be accessed through the proxy provided in the Location field. The Location field provides the URI address of the proxy. The receiver wants to repeat this single request through the proxy. The 305 response must be generated only by the source server.

      The NOTE:RFC 2068 protocol is unclear whether 305 intends to redirect a single request and is generated only by the original server. Non-compliance with these restrictions can have significant security consequences.

10.3.7 306 (deprecated)

306 The status code is used in the previous version of this specification and is no longer used, and the code is retained.

10.3.8 307 Temporary Redirect (Temporary Redirect)

The requested resource is temporarily stored under another URI. Because the redirect can sometimes be modified, future client requests still use the original request URI. The response is cached only if the Cache-control or Expires header field description is used.

The address of the temporary URI needs to be given in the location in the response. Unless the request method is head, the responding entity should contain a short hypertext comment with a hyperlink to the new URI, because many http/1.1 previous versions of the user agent do not understand the 307 state. Therefore, the comment should contain the information that the user needs to restart the original request on the new URI.

If a 307 status code is received in the response, but the request method of the response is not head or get, the user agent must not automatically redirect the request unless it has been confirmed by the user, as this may change the condition when the request is made.

10.4 Client Error 4xx

The status code for the 4xx class is to describe the client error. In addition to responding to head requests, the server should contain an entity with an explanation of the error condition and whether it is temporary or permanent. This type of status code applies to any Request method. The client agent needs to display any entity content that is contained in the response for the user.

If the client is sending data, the server implementation using TCP should ensure that the client confirms receipt of the packet that contains the response before the server closes the input connection. If the client continues to send data to the server after shutting down, the server's TCP stack sends a reset package to the client, which may clear the client's unacknowledged input buffer before the HTTP application reads and interprets it.

10.4.1 400 Illegal requests (Bad request)

The server was unable to understand the request due to a syntax error. The client should not repeat the request without modification.

10.4.2 401 Unauthorized (Unauthorized)

The user's identity needs to be verified when the request is made. The response must contain a Www-authenticate header field (14.47 bars) for the query that applies to the requested resource. The client can repeat the request (section 14.8) with the appropriate Authorization header field. If the request already contains information about authorization validation, then a 401 response indicates that the certificate has been denied authorization. If the 3-1 response contains the same query information as the previous response, and the user agent has tried authentication at least once, then the entity given in the response is displayed to the user because the entity may include relevant diagnostic information. HTTP asks for a detailed description of the relevant authentication in "HTTP Authentication: Concise access authentication [43]".

10.4.3 402 Payment requirements (Payment Required)

This status code will provide a way to use it in the future.

10.4.4 403 rejected (Forbidden)

The server understands the request, but rejects the request. Authorization is not helpful, and requests should not be duplicated. If the request method is not head and the server wants to expose why the request was not completed, it should explain the reason for the rejection in the entity. If the server does not want this information to be available to the client, then the 404 status code can be used instead.

10.4.5 404 Not Found (not Found)

The server did not find anything on the matching request URI. There is no indication that the situation is temporary or permanent. If the server knows that the old resource is permanently unavailable and has no forwarding address through some internally configurable mechanisms, the 410 (Gone) Status code should be used. This status code is typically used when the server does not want to show exactly why the request was rejected, or when no other response is applicable.

10.4.6 405 Methods not allowed (method not allowed)

The method specified in the request line is not allowed for the resource identified in the request URI. The response must contain an Allow header field that contains a list of methods that are valid for the requested resource.

10.4.7 406 unacceptable (not acceptable)

The resource identified by the request can only generate response entities with unacceptable content characteristics based on the Receive header fields sent in the request.

Unless it is a head request, the response should include an entity with a list of available entity features and locations, from which the user or user agent can select the most appropriate entity content. The entity format is specified by the media type given in the Content-type header field. Depending on the format and ability of the user agent, the most appropriate choice can be performed automatically. However, the specification does not define any criteria for this automatic selection.

      Note: The server allows an unacceptable response to be returned based on the request headers sent in the request. In some cases, this might even be better than sending a 406 response. We encourage the user agent to check the headers of incoming responses to determine if they are acceptable.

If the response is unacceptable, the user agent should temporarily stop receiving more data and ask the user to decide on further action.

10.4.8 407 requires agent authentication (proxy authentication Required)

This status code is somewhat similar to 401 (unauthorized), but indicates that the client must first authenticate with the proxy. The agent must return a Proxy-authenticate header field (section 14.33) that contains inquiries about the agent that is applicable to the requested resource. The client needs to include an appropriate proxy-authorization header field when repeating the request. HTTP-related access validation instructions are described in more detail in "HTTP Authentication:basic and Digest access authentication" [43].

10.4.9 408 Requests timeout (Request timeout)

The client does not generate the request within the time the server is ready to wait. The client can repeat the request at any later time without making any changes.

10.4.10 409 conflict (Conflict)

The request could not be completed because of a conflict with the current state of the resource. This code is allowed only if the intended user is able to resolve the conflict and resubmit the request. The body needs to contain enough information to make the user aware of the conflict of the resource. Ideally, the response entity will contain enough information to the user or user agent to resolve the problem, however, this may not be possible and is not required.

Conflicts are most likely to occur when responding to put requests. For example, if the current resource is using version control, the resource that will be put contains some modifications that can also cause a conflict with a previous (or third-party) request, and the server needs to use a 409 response to indicate that it cannot complete the request. In this case, the response entity may contain a list of differences between the two versions, which are defined by the Content-type in the response.

10.4.11 410 Deleted (Gone)

The requested resource has not been provided by the server and there is no known address to point to the resource. This situation is expected to be considered permanent. A client with link editing functionality should remove a reference to the request URI after the user approves it. If the server does not know, or if there is no definite condition to know whether its state is permanent, then the 404 status Code should be used. Unless otherwise noted, the response can be cached.

A 410 response is primarily a task that assists web maintenance by notifying the recipient that the resource is unavailable, and the server owner wants to remove the remote link to the resource. Such a situation is common for resources that have time-limited resources, promotional services, and individuals who are no longer working on the server site. You do not have to mark all permanently unavailable resources as "used (GONE)", nor do you need to keep the tags for any time – this is the sole discretion of the server owner.

10.4.12 411 Required Length (lengths Required)

The server refuses to accept a request without a content-length header field. If the client adds a valid Content-length header field that contains the message body length in the request message, the request can be repeated.

10.4.13 412 does not meet the prerequisites (precondition Failed)

When the request header field is tested on the server, the prerequisites given in one or more request header fields are evaluated as false. This response code allows the client to place prerequisites on the current resource's meta-information (header field data), thereby preventing the requested method from being applied to resources other than the expected resource.

10.4.14 413 Request Entity is too large (ask entity Too Large)

The server refuses to process the request because the request entity is larger than the scope the server wants or can handle. The server may close the connection to prevent the client from continuing the request.

If the condition is temporary, the server should include the Retry-after header field to indicate that it is temporary and when the request can be tried again.

10.4.15 414 Request URI too long (Request-uri Too long)

The server refused to service the request because the request URI was too long to exceed the limit that the server could resolve. This rare situation can only occur when the client transforms a POST request into a GET request with too long query information, when the client enters the URI redirection "black hole" (for example, the prefix of a redirect Uri points to its own suffix). Or, when the server is attacked by a client, it attempts to use a fixed-length buffer to read or manipulate the request URI by reading the security holes in some servers.

10.4.16 415 Unsupported media types (Unsupported media type)

The server refuses to service the request because the requested entity is a format that is not supported by the resource that is requested using the request method.

10.4.17 416 Unmet Request range (requested range not satisfiable)

If a request contains a range request header field, and the range specifier value in this field does not overlap the current scope of the selected resource, and the request does not have a If-range request header field, the server should return the status code in the response. (For the Byte-ranges field, it indicates that the first byte value in all byte ranges is greater than the current length of the selected resource.) ）

When the status code is returned in response to a byte-range request, the response needs to include a Content-range entity header field that describes the length of the currently selected resource (see section 14.16 for details). The response cannot use the Multipart/byteranges type.

10.4.18 417 does not meet the information identified by the Expect header field (expectation Failed)

The server does not meet the expectations in the Expect header field (see section 14.20), or if the server is a proxy server, the server has clear evidence that the request cannot be met by the next hop (next-hop) server.

10.5 Server errors (server error) 5xx

A response status code that begins with the number "5" indicates that the server is aware that it is faulty or unable to execute the request. In addition to responding to header requests, the server should return an entity that contains an explanation of the error condition, and whether it is a temporary or permanent state. The agent should present all the entity content to the user. These response codes are suitable for any request method.

10.5.1 500 Internal server errors (Internal server error)

The server encountered an unexpected condition that prevented it from completing the corresponding request.

10.5.2 501 Not implemented (not implemented)

The server does not support the functionality required to complete the request. The response should be returned when the server does not recognize the requested method or cannot provide any resources.

10.5.3 502 Bad Gateway

The server acts as a gateway or proxy and receives an invalid response from the upstream server when it attempts to execute the request.

10.5.4 503 Services Unavailable (Service unavailable)

The server is currently unable to process the request due to temporary overloading or maintenance of the server. This means that this is a temporary state that will be mitigated after some delay. If the time of the delay is known, the length of the delay may be expressed in the Retey-after header field. If the Retry-after field is not provided, the client should process the response as if it were handling a 500 response.

The presence of the note:503 status code does not mean that the server must use it when it is overloaded. Some servers may simply want to reject the connection.

10.5.5 504 Gateways Timeout (Gateway timeout)

The server acts as a gateway or proxy and does not receive a prompt response from a URI (such as HTTP, FTP, LDAP) or an upstream server specified by another secondary server (such as DNS) that needs to be accessed when attempting to complete the request.

      Note: Developer notes: When DNS lookup times out, some deployed proxies are known to return 400 or 500.

10.5.6 505 Unsupported HTTP version (HTTP version not supported)

The server does not support or deny the HTTP protocol version used in the support request message. The server indicates that it cannot or does not want to use the same major version as the client to complete the request, as described in section 3.1, rather than using this error message. The response should contain an entity that explains why this version is not supported and which other protocols the server supports.

Rfc2616-http1.1-status Code (Status Code Provisions section-translated)