HTTP 100 status code
100 (Continue) The requester should continue making the request. The server returns this code to indicate that it has received the first part of the request and is waiting for the remainder.
The server determines whether to accept the client's request based on the client's request header. If the request is accepted, it responds with a 100 status code. The server determines whether it is an Expect request based on whether there is an Expect: 100-continue request header (some web servers cannot handle Expect requests correctly)
This status code indicates that the server has received The initial part of the request is reached and the client is asked to continue sending. After the server sends the 100 Continue status code, it must respond if it receives a request from the client.
This status code is actually an optimization for the following scenario: the client has a larger file that needs to be uploaded and saved, but the client does not know whether the server is willing to accept the file, so it hopes to consume the network Before transferring resources, ask the server for its wishes. The actual operation is for the client to send a special request message. The header of the message should contain
Expect: 100-continue
. At this time, if the server is willing to accept it, it will return a 100 Continue status code, otherwise it will return a 417 Expectation Failed status. code. For the client, if the client does not intend to send an actual request, it should not send a message containing 100 Continue Expect, because this will make the server mistakenly think that the client is about to send a request.
As mentioned before, not all HTTP applications support the 100 Continue status code (such as HTTP/1.0 and previous versions of proxies or servers), so the client should not continue to send 100 Continue Expect after Waiting for the server's response, after a certain period of time, the client should directly send the content planned to be sent.
As for the server, 100 Continue should not be regarded as a strict judgment method. The server may have received the body message from the client before sending the response. At this point the server no longer needs to send 100 Continue as a response. But still need to return the appropriate status code after the acceptance is complete. In theory, when the server receives a 100 Continue Expect request, it should respond. But the server should never send a 100 Continue status code in response to a client that did not send a 100 Continue Expect request. The response mentioned here means: assuming that the server does not intend to receive the body message to be sent by the client, it should also make an appropriate response (such as sending 417 Expectation Failed) instead of simply closing the connection, which will cause problems for the client. Impact at the network level.
Specially, the HTTP application as a proxy needs to make additional judgments when receiving a request with 100 Continue Expect. Assuming that the proxy server clearly knows that the HTTP version downstream of the message is compatible with HTTP/1.1, or the proxy server does not know the downstream version of the message, it should forward this 100 Continue Expect request. However, if the proxy server clearly knows that the application downstream of the message cannot handle 100 Continue Expect, it should directly return 417 Expectation Failed to the client as a response. And this is not the only solution. Another feasible way is to directly return 100 Continue to the client, and then pass the message with 100 Continue Expect deleted to the downstream.
In addition, if the proxy server decides to serve HTTP/1.0 and previous versions, then when it receives a 100 Continue response message from the server, it should not forward this response to the client because The client most likely doesn't know what to do with the message.
