Re: curl_schannel.c and realloc()
Date: Tue, 19 Jun 2012 10:38:07 +0200
> 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
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
- application/octet-stream attachment: 0001-curl_schannel.h-Use-BUFSIZE-as-the-initial-buffer-si.patch