The only way I could get the Ssl routines to communicate at all with my server was to set the netSocketOptSockNonBlocking _after_ the SslOpen handshake, and keep it set thereafter. Any other changes to that flag in the socket would cause the Ssl commands to simply hang. But with that socket option set, SslOpen succeeds, it proceeds to do an SslSend to send a POST command, and then does an SslRead, which seems to read the complete server response, but also sets the SslContext error to netErrWouldBlock, killing the conversation. Setting the Context's ReadStreaming or not doesn't affect the outcome. Trying to learn something from the socket or SslContext didn't give any clues. I tried to do a couple NetLibSocketOptionGet for any socket error and to check the blocking status thoughout the app, but they always return netErrUnimplemented (even though the docs say they are implemented). I also looked at most of the SslContext attribs, and didn't see any alarming changes to the SslContext from before to after the SslRead (I see a few changes in the SslSession.sessionid and SslSession.mastersecret, but I don't know if that should be alarming). Jason
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
