> I don't know. Can you show us a recipe on how to reproduce this problem? Your description hasn't been detailed enough for me to understand.

I tried reproducing this problem with pure CURL and our server. What I found is that returning exact number of read bytes from CURLOPT_READFUNCTION callback causes server to hang. Our read function receives 16384 byte buffer from CURL, fills it and returns number of bytes read. If we reach end of upload body - we return what was left to read - for example 2304. Returning 2305 (read bytes count incremented by one) for some reason fixes this issue.

Tested workflow, each request creates new CURL handle and uses same CURLM handle:
1. [Application specific] Send upload handshake request with some initial data, receive 308 and ETag to use with each chunk
2. Upload 4 000 000 bytes chunk. Read function calls return 16384 (244 times) and then 2304, receive 308
3. Upload 4 000 000 bytes chunk. Read function calls return 16384 (227 times) and server hangs

Reproduces if:
- HTTPS (HTTP works)
- Windows Server 2008 (2012 works)
- Using same CURLM (using seperate CURML handles or seperate CURL hangles works)
- Returning exact number of bytes that were read to buffer (works if returning same buffer size or incrementing value by one when read less than buffer size)

http://curl.haxx.se/libcurl/c/CURLOPT_READFUNCTION.html mentions bug and server "hangs" in some workflows, can that be related to this?

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-05-25