1
votes

RFC 2616: http://tools.ietf.org/html/rfc2616#section-8.2.3

  • An origin server SHOULD NOT send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue" expectation.
  • There is an exception to this rule: for compatibility with RFC 2068, a server MAY send a 100 (Continue) status in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header field with the "100-continue" expectation. The purpose of which is to minimize any client processing delays associated with an undeclared wait for 100 (Continue) status.

I do not understand that explained purpose. Why the server would send something if it already knows it is not expected ? A client will not know what to do with that if it doesnt expect it. It has no choice but to ignore it. But then, why bother sending it ?

If the client sends a PUT or POST request message that has a body, it will include "Expect: 100-Continue" header if it will wait for a confirmation before sending the body, or it will send the body directly. If it chose to send it directly, the body will be sent before the server can send the "100-Continue" response, and if the client receicve that response when it has nothing left to send, what it would do whit it ?

I've also read the other questions regarding 100-Continue response but I got no answer...

1

1 Answers

0
votes

RFC 2068 didn't include the "Expect: 100-continue" header. A server receiving an HTTP 1.1 request was required to send a 100-Continue response before receiving the request body:

Upon receiving a method subject to these requirements from an
HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either respond with 100 (Continue) status and continue to read from the
input stream, or respond with an error status.

Later, RFC 2616 included the Expect header, but allowed servers to send a 100-Continue response for those clients that where implemented before and might be waiting for it.