I believe this is actually a bug, because it causes the posting of messages whose length is greater then the Apache HTTPD SSLRenegBufferSize setting to fail, whereas other http clients that first wait to receive the 100 response before sending the body do work.

The situation I am encountering is an Apache server that uses client certificates to authorize calls to it's rest apis, whereas the rest of the same site do not require it. See the documentation about the SSLRegenBufferSize here: https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslrenegbuffersize

By sending just the headers first with the "Expect: 100-continue" header and then waiting for the "100" response, Apache only has to buffer the headers. But the way HTTPConnection currently works, the headers and the body will be sent immediately, causing the SSLRenegBuffer to be exceed, causing the request to fail.

Also, I do not think the submitted patch is the best fix for this. The HTTPConnection.putheader method should be the place that checks to see if there is an Expect header sent.