Marc, Daniel, All, Thinking about this a little bit more, I wonder if the SSL write function really needs to write ALL the bytes the client passes in before it returns. Here's why. Suppose the client passes in 100 bytes of data to write (a small HTTP GET request). When we use SSL, we may encrypt that 100 bytes into a different number of bytes; it depends on the encryption algorithm that was negotiated (without extra work we're not going to even know which one was used). Suppose the plain bytes are converted into 125 bytes. If we write only the first 30 bytes, and we return that to the client, they will call the write function again and start us off at position 30. Since the previous message was not written fully, it probably wasn't coherent to the receiver when it was decrypted. Writing 30 bytes (of encrypted data) may not mean that 30 bytes of the unencrypted data was decrypted by the client.
What do you guys think? Do you agree? When ssl write methods are passed a buffer to write do they need to write it all or return an error if they are unable to, respecting configured timeouts? Any encryption experts want to weigh in? Mark -----Original Message----- From: curl-library-boun...@cool.haxx.se [mailto:curl-library-boun...@cool.haxx.se] On Behalf Of Marc Hoersken Sent: Monday, April 23, 2012 12:15 PM To: libcurl development Subject: Re: SSL/TLS support using Windows SSPI Schannel API 2012/4/23 Daniel Stenberg <dan...@haxx.se>: > On Mon, 23 Apr 2012, Salisbury, Mark wrote: > > Thanks a lot for your contribution Mark. Let's combine these into > something great! > Yep, I am also for combining the solutions into something great! > >> - write buffering implemented (though this is very easy to do). it >> continues in a loop until all bytes are written. Not sure if this is >> what Daniel intended as correct when he said "The code considers >> swrite() returns that are less than "full" to be errors.". The >> alternative is to maintain a 'bytes to write' buffer an check that first >> when a send call is invoked. > > > That's the issue I meant, yes. Just looping is however not the ideal > solution since that is a blocking behavior which will waste CPU cycles > and degrade the multi interface experience. It is however better than > not handling the case at all... =) > What about returning CURL_AGAIN? Will this make libcurl re-call the functions for further writing? > >> See my implementation attached. (of course there are some changes in >> some other libcurl header files too, just the main implementation >> file is attached). > > > Mark and Marc! What do you consider the best way forward to be? > > Will you merge your two efforts first, or should we get one of them > into the master first and then work on adjusting that with code from > the other way afterwards? I'm open for either way. I guess Mark's solution is more mature, but he also correctly identified advantages in both implementations. As I am pretty busy until the 7th May, I am not sure if I can help much with the merge, but I would really like to see the advantages of both approaches being merged into libcurl. Best regards, Marc ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
