HTTP 1.1 Status Code Definitions

Document directory

• 8.2.3 use of the 100 (CONTINUE) Status
• 10.1.1 100 continue
• 10.1.2 101 switching protocols
• 10.2.2 201 created

The first line of the RFC 2616 publish status-lineresponse message is status-line, which contains the HTTP Version Information, status code, and the signed phrase related to the status code, separated by spaces:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

6.1.1 status code and reson phrase

The three-digit status code is used to respond to different requests from the client. For more information, see section 10. Classification of the status code first used to identify the status code:

- 1xx: Informational - Request received, continuing process      - 2xx: Success - The action was successfully received,        understood, and accepted      - 3xx: Redirection - Further action must be taken in order to        complete the request      - 4xx: Client Error - The request contains bad syntax or cannot        be fulfilled      - 5xx: Server Error - The server failed to fulfill an apparently        valid request

Status-Code    =            "100"  ; Section 10.1.1: Continue          | "101"  ; Section 10.1.2: Switching Protocols          | "200"  ; Section 10.2.1: OK          | "201"  ; Section 10.2.2: Created          | "202"  ; Section 10.2.3: Accepted          | "203"  ; Section 10.2.4: Non-Authoritative Information          | "204"  ; Section 10.2.5: No Content          | "205"  ; Section 10.2.6: Reset Content          | "206"  ; Section 10.2.7: Partial Content          | "300"  ; Section 10.3.1: Multiple Choices          | "301"  ; Section 10.3.2: Moved Permanently          | "302"  ; Section 10.3.3: Found          | "303"  ; Section 10.3.4: See Other          | "304"  ; Section 10.3.5: Not Modified          | "305"  ; Section 10.3.6: Use Proxy          | "307"  ; Section 10.3.8: Temporary Redirect          | "400"  ; Section 10.4.1: Bad Request          | "401"  ; Section 10.4.2: Unauthorized          | "402"  ; Section 10.4.3: Payment Required          | "403"  ; Section 10.4.4: Forbidden          | "404"  ; Section 10.4.5: Not Found          | "405"  ; Section 10.4.6: Method Not Allowed          | "406"  ; Section 10.4.7: Not AcceptableFielding, et al.            Standards Track                    [Page 40]RFC 2616                        HTTP/1.1                       June 1999          | "407"  ; Section 10.4.8: Proxy Authentication Required          | "408"  ; Section 10.4.9: Request Time-out          | "409"  ; Section 10.4.10: Conflict          | "410"  ; Section 10.4.11: Gone          | "411"  ; Section 10.4.12: Length Required          | "412"  ; Section 10.4.13: Precondition Failed          | "413"  ; Section 10.4.14: Request Entity Too Large          | "414"  ; Section 10.4.15: Request-URI Too Large          | "415"  ; Section 10.4.16: Unsupported Media Type          | "416"  ; Section 10.4.17: Requested range not satisfiable          | "417"  ; Section 10.4.18: Expectation Failed          | "500"  ; Section 10.5.1: Internal Server Error          | "501"  ; Section 10.5.2: Not Implemented          | "502"  ; Section 10.5.3: Bad Gateway          | "503"  ; Section 10.5.4: Service Unavailable          | "504"  ; Section 10.5.5: Gateway Time-out          | "505"  ; Section 10.5.6: HTTP Version not supported          | extension-code      extension-code = 3DIGIT      Reason-Phrase  = *<TEXT, excluding CR, LF>

HTTP status codes are eXtensible. That is to say, custom client clients can customize some status codes. The defined client program should understand the meaning of five types of status code pigeons. Once an incomprehensible status code is received, it will be equivalent to the x00 status code of the class. For example, if an unknown 431 error occurs, the same 400 error occurs. at this point, the User Token should display the entity returned along with response to the user, because these entity may contain human readable information which will explain these incomprehensible status codes, such as 431.

8.2.3 use of the 100 (CONTINUE) status code is used by the client to determine whether the source server wants to accept the request body following the request header ). That is to say, after the client sends a request header containing the exception field, it determines whether the request body of the same request must be sent based on the respose status code returned by the server.

Requirements for HTTP/1.1 clients:

--- If a client decides not to send the request body for the moment, and waits for the server to return the status code 100 before sending the request, it must first send a request containing the "100-continue" exceptin header. See section 14.20 of this agreement.

--- If the client does not decide to send the request body, Never send a request containing the exception value "100-continue.

Because the old HTTP protocol is still in use, the behavior definition when http1.1 sends "exceptionp: 100-continue" to the client and does not receive the 417/100 status code reponse is vague. Therefore, if the client does not wait for the 100 status code response of the server segment, do not wait until the request body is directly sent.

Requirements for HTTP/1.1 origin servers:

--- Once a request containing "exception: 100-continue" is received, the source server will not return a 100 status code response and continue to read data from the input stream, you do not need to end with a termination status code. The source server should not wait for the request body to send a 100 status code response. If a termination status code is returned, the server may act in a variety of ways, closing the connection, or continuing to read and ignore other parts of the request, if the server chooses to return the termination status code, it cannot be the method for executing the request.

--- When the client does not display a request that adds the "Tin: 100-continue" header, the server should not send a 100 status code response. For clients that do not support http1.1, this response should not be sent. But there is a special case: to be compatible with RFC 2068, in an HTTP/1.1 put or POST request, even if the request does not contain the "exception: 100-continue" field, the server may also send a 100 status code response, because this can minimize the waiting for the client to respond to the 100 status code that is not reported.

--- If the server has received some or all request bodies, it should send a 100 status code response.

--- Unless the connection is too early, the source server must return a termination response when receiving and processing the request body.

--- If the server is processing a request containing the request body, the request does not contain the header "excpetin: 100-continue, the server returns a response with a termination status code before reading the entire request body. The server should not close the connection unless the server completes the entire request or the client closes the connection. Otherwise, the client cannot receive reliable response messages. However, this requirement should not be interpreted as a denial-of-service attack to protect the principle of service, nor to prevent the implementation of junk clients.

Requirements for HTTP/1.1 proxies:

--- If the proxy server receives a request containing the "exception: 100-continue" header and does not know whether the server to be jumped is compatible with http1.1 or a later version, or if you do not know the HTTP protocol version compatibility of the next hop server, you must forward the request and include the original exception header.

--- If the proxy server can see that the HTTP compatibility of the next hop server is 1.0 or even lower, the request cannot be forwarded, and the proxy server must respond to a 417 response. --- The proxy server should make a cache record for the HTTP compatibility of the next hop server of the recent application. --- If the HTTP compatibility of the client is 1.0 or lower, the proxy server should not forward the 100 status code response or insert "exception: 100-continue "header. This requirement prevails over general rules (see section 10.1) before (overrides). 10. Status Code definition

The description of each status code below contains the request method supported by it, and other metadata required for setting this status code in reponse. Sometimes, it is inappropriate and inefficient for the server to reject requests without knowing the content of the request body.

10.1 informatinal 1xx

This type of status code is a temporary response. It only contains status-line and optional headers and ends with a blank line. No header is required for this type of status code. Because http1.0 does not define any status code of this class, the server cannot send the response of this class to the http1.0 client unless you just want to experiment with it.

Before a common response, the client's default state is ready to accept one or more class response, even if the client does not send a request to obtain such a response from the server. In other words, the client should be ready to accept such response at any time. Sometimes the response of this class is ignored by the user proxy.

The proxy server must forward the response of this class unless the connection between the proxy server and the client has been closed, or unless the request is initiated by the proxy server itself. In other words, the proxy server always forwards the class response from the server to the client. (For example, if the Proxy Server adds the exception header of 100-continue to the forwarded request, this class of response does not need to be forwarded ).

10.1.1 100 continue tells the client to continue sending the remaining part of the same request, or ignore this response if the request has been sent. The server should provide a termination response when the request is completely processed. For details, see section 8.2.310.1.2 101 The switching protocols server understands the client request and will notify the client to use different protocols to complete the request through the upgrade message header. 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. 10.2 successful 2XX indicates that the request has been successfully received, understood, and accepted by the server. 10.2.1 200 OK request succeeded. The returned information depends on the method in the request, for example: get an entity corresponding to the requested resource is clipped. in the response, the entity-header fields corresponding to the requested resource in the head response is sent in the response, there is no message-body in the response. Post a description or entitytrace containing the result action an entity10.2.2 201 created request received by a North-end server has been processed and a new resource has been created, the new resource can be accessed by the URI (s) returned by the age Location header.