One of our unit tests for code that sits on top of libcurl identified
a problem when we upgraded from curl-7.20.0 to curl-7.21.3. The test
starts an HTTP GET with a timeout (via CURLOPT_TIMEOUT_MS) from a URI
that provides the body only very slowly. After a while the request
times out and the test tries to continue from where it left off using
CURLOPT_RESUME_FROM. This second request fails immediately with
CURLE_RANGE_ERROR.

A wireshark capture showed that libcurl was continuing to use the same
HTTP connection for the second request even though the server was
still slowly providing data from the previous one. It looks like the
first libcurl knew of this was when it failed to see a Content-Range
header.

Bisecting showed me that the problem only started occurring in commit
3880dd3741204965dde312643a18190a24c66ba9. It may be that this commit
subtly changed the timing or perhaps because it caused the timeout to
be handled by a different bit of code.

I can still reproduce the problem at the current git HEAD
(66582c04b169d84d4c63350f7d7b282e4f8b8128)

The following patch stops the connection being re-used and fixes the
problem for me but I'm not convinced that this is the best way to fix
it.

--- a/lib/multi.c 2011-02-17 13:09:11.502664507 +0000
+++ b/lib/multi.c 2011-02-17 13:08:50.530755986 +0000
@@ -1003,6 +1003,10 @@ static CURLMcode multi_runsingle(struct
                 Curl_tvdiff(now, data->progress.t_startsingle), k->bytecount,
                 k->size);
         }
+
+ /* Force the connection closed because the server could
+ continue to send us stuff at any time. */
+ easy->easy_conn->bits.close = TRUE;
         easy->result = CURLE_OPERATION_TIMEDOUT;
         multistate(easy, CURLM_STATE_COMPLETED);
         break;

Does this look like the real cause or have I got myself very confused?

Thanks.

Mike.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-02-17