Hi Daniel,

> On Wed, 13 Jun 2012, Marc Hoersken wrote:
>
>>> I was first going to agree and then a second thought struck me. Why would
>>> it ever need to handle more data? If it gets called asking for 20K of data,
>>> there's nothing in the API that says the function must return that much. We
>>> can safely just make BUFSIZE the maximum amount of data the schannel_recv()
>>> function can return without it breaking any properly written code!
>>>
>>> It would simplify the code without breaking anything...
>>
>>
>> That's a good plan.

I gave this another thought and figured out that we also still need to
be able to handle more data internally than BUFSIZE. For the same
reason we actually need the internal buffers, which I explained
earlier in this thread, we also need to be able to handle more data
being received and decrypted internally. Especially since
length(encrypted) != length(decrypted) as SSL/TLS supports compression
and of course the encrypted data stream contrains SSL/TLS packet
information.

Therefore I created a patch that sets up
CURL_SCHANNEL_BUFFER_INIT_SIZE to BUFSIZE and
CURL_SCHANNEL_BUFFER_STEP_SIZE to BUFSIZE/2 if BUFSIZE is available.

Do you have any other input on this? Otherwise I would be fine with
this patch being pushed. It is based upon the current master
8a8829499d91967f952408251d8aa2343fff1c55.

Best regards,
Marc

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html