Thanks for the clarification. However, I'm still not quite sure what is supposed to be wrong in the customer's situation:
"why it returned 100 Continue when I PUT with Expect100Continue set in the customer's situation"
- This looks like exactly what is supposed to happen when Expect100Continue is set.
"it did not upload automatically and returned a 'Continue' response."
- Basically, with Expect100Continue enabled, the client is supposed to wait for "100 Continue" response from the server, and then send the data. But if the response does not arrive within ContinueTimeout ms, it's supposed to start sending data anyway.
For detailed information on this, please refer to the RFC:
1) Default value for .NET's HttpWebRequest is 350ms as well.
2) This is tricky. An optimal value might be the round-trip time + the time it takes the server to respond + a bit of extra time. However, there is not really a single value that suits all scenarios. If there were, it would be recommended by relevant RFCs.
3) Again, this is where I'm not don't understand your customer's scenario correctly... Both "100 Continue received" / "100 Continue not received" situations are handled internally by Rebex HttpRequest or .NET's HttpWebRequest. It's not up to the application to decide how to handle them, and in fact, this behavior is hidden from the client app by HttpRequest/HttpWebRequest API.
3.1) I'm not sure what "again" means in this context. With Expect100Continue, there is supposed to be one "100 Continue" response and one "normal" response (such as "200 OK" or an error response). There are not suppose to be two "200 OK" responses, which seems to be implied by "again" in your question.
3.2) When "100 Continue" is received from the serve, the only correct behavior for the client is to continue by sending the request body. I would make no sense to close the connection at that point.