I have now managed to send a request manually to my web service using a
HttpWebRequest object over HTTPS. The setting which seems to be causing
the problem is AllowWriteStreamBuffering - when this is set to true and
a ContentLength is not specified, I get the same error as I get when
sending my request using the web service APIs. If is set
AllowWriteStreamBuffering to false and specify a ContentLength, the
request is dispatched correctly.

To give some extra information on my original problem, we were sending
a message of length 428 characters to the web service. When the server
reads from the stream, the first 256 characters of that message have
been cropped. It then receives up to the end of the message correctly,
then it receives a *second* copy of the message, but with the first 172
characters cropped from the start. The result is a message of length
428, as expected, containing two partial copies of the message with
differing numbers of bytes missing from the front.

It may be coincidence, but when you inspect the internals of the stream
that is provided by HttpWebRequest.getRequestStream() with
AllowWriteStreamBuffering to true, the first buffer it creates is of
length 256.

Does anyone know why this would be happening when I make HTTPS
requests? We have been tearing our hair out for three days trying to
get to the bottom of this problem. Right now we are considering writing
a custom WebRequest implementation which wraps a HttpWebRequest with
AllowWriteStreamBuffering set to false, and sets the content length and
streams through the message once the full message has been written to
the custom implementation's request stream. I can only hope that will
work...