For SSL URLs (e.g. https://login.yahoo.com/), HttpWebRequest.GetRequestStream() and HttpWebRequest.GetResponse() fails with WebException. Exception status is ‘ReceiveFailure’ and message is ‘Unable to read data from the transport connection’.
The server sends an empty encryption packet to the NetCF client. The trouble with NetCF’s SSL stack is when the server encrypts a buffer of zero length and sends it to the client. Although the original data had a length of zero, the encrypted version of it actually has a non-zero length. When this packet is sent to a NetCF client, current versions of NetCF decrypt the packet and return a zero length buffer to the caller. The semantics of a network Read method is traditionally that it blocks until some data is received, and if a zero length buffer is returned it is the sign that the socket was closed. Because NetCF will return an empty buffer after decrypting an “empty” encryption packet, the caller may misinterpret this as a sign of a disconnected socket and terminate the connection. In fact this is exactly what happens in NetCF’s web services code when calling services over SSL that respond with empty encryption packets. As a result the connection fails before the response is fully received and an exception is thrown.
None. But a detector for this problem is available at http://code.msdn.microsoft.com/emptysslpackets