The problem is that, because CommonsHTTPSender.MessageRequestEntity#getContentLength() is defined to only return a content-length when the HTTP version is 1.0 *and* no exception is thrown from message.getContentLength(), then it will not even try if the HTTP version is 1.1. The upshot of this is that a Transfer-Encoding: chunked header is set on the request.
This makes sense, since Transfer-Encoding should be supported by a HTTP 1.1 server. However, it happens to cause the server I'm communicating with to barf and drop the connection. This is almost certainly a bug in the server, however, if the content-length is sent, then no barfing occurs.
Is there any reason, if a content-length value is available, that Transfer-encoding should be set? If it were the default for it to attempt to set the content-length, then this would solve my problem. Otherwise, I'll have to maintain a forked version which does exactly this, just to maintain communication with my server.
Ta,
-- Mike
