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...