The 'expect: 100-continue' related code has been significantly refactored - the overall design should have gotten simpler and cleaner - CPU-bound response polling (busy wait) in WaitForResponse which somehow might have been contributing to the problem has been removed in favour of a more elegant solution suggested by Simon Roberts <[EMAIL PROTECTED]> that relies on the socket timeout - RFC 2616 compliance problem has been fixed. 1xx range status codes should never be returned from the HttpClient#executeMethod. Unexpected 1xx status code are now ignored and discarded as specified in the RFC 2616
This said, sadly enough I still have no idea what have been causing 100 response to time out in the very first place. I really need more input from you. I am kindly asking you to re-test your applications with the newest CVS snapshot and provide me with additional feedback. As far as I understand, the problem (if it has not been eliminated by the redesign and the busy wait fix) should now be manifesting itself through warning messages in the log only. Please watch for the following messages in the logs: [INFO] HttpMethod - -100 (continue) read timeout. Resume sending the request ... [INFO] HttpMethod - -Discarding unexpected response: HTTP/1.1 100 Continue If you succeed in reproducing the problem, I would appreciate your sending me instructions as to how the problem can be reliably reproduced. A test case would be a fantastic and much appreciated contribution Cheers Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
