Mailing Lists
|
cURL Mailing List Monthly Index Single Mail
curl-tracker Archives
[curl:bugs] #1334 Timeout issue in code handling 100-continue
From: Daniel Stenberg <bagder_at_users.sf.net>
Date: Thu, 06 Feb 2014 22:22:37 +0000
- **status**: open --> closed-fixed
--- ** [bugs:#1334] Timeout issue in code handling 100-continue ** **Status:** closed-fixed **Created:** Thu Feb 06, 2014 05:16 PM UTC by Remi Gacogne **Last Updated:** Thu Feb 06, 2014 05:16 PM UTC **Owner:** Daniel Stenberg Hi, I think there may be an issue with the way libcurl 7.35.0 is handling the case of a server not sending a 100 (Continue) response after an Expect: 100-continue header has been sent. When using the multi socket interface, libcurl calls the curl_multi_timer_callback asking to be woken up after CURL_TIMEOUT_EXPECT_100 milliseconds (the timeout is set in Curl_setup_transfer()). ~~~~~~ /* Set a timeout for the multi interface. Add the inaccuracy margin so that we don't fire slightly too early and get denied to run. */ Curl_expire(data, CURL_TIMEOUT_EXPECT_100); ~~~~~~ After the timeout has expired, calling curl_multi_socket_action with CURL_SOCKET_TIMEOUT as sockfd leads libcurl to check expired timeouts. When handling the 100-continue one, the following check in Curl_readwrite() fails if exactly CURL_TIMEOUT_EXPECT_100 milliseconds passed since the timeout has been set: ~~~~~~ long ms = Curl_tvdiff(k->now, k->start100); if(ms > CURL_TIMEOUT_EXPECT_100) { ~~~~~~ As the event has now expired, it is discarded and the corresponding request will never succeed. The following patch (proper git-formatted version attached) is working fine in our tests, and it seems logical to consider that having waited for CURL_TIMEOUT_EXPECT_100 ms is enough : diff --git a/lib/transfer.c b/lib/transfer.c index 3408a84..f996b0e 100644 --- a/lib/transfer.c +++ b/lib/transfer.c @@ -1075,7 +1075,7 @@ CURLcode Curl_readwrite(struct connectdata *conn, */ long ms = Curl_tvdiff(k->now, k->start100); - if(ms > CURL_TIMEOUT_EXPECT_100) { + if(ms >= CURL_TIMEOUT_EXPECT_100) { /* we've waited long enough, continue anyway */ k->exp100 = EXP100_SEND_DATA; k->keepon |= KEEP_SEND; It seems this was not an issue before this commit (at least not exactly in the same way): https://github.com/bagder/curl/commit/3b183df9cc781b329ca409ded1ea336530624715 It seems that the previous commit expected this case to be taken care of by this commit, but it does not seem to be the case: https://github.com/bagder/curl/commit/980659a2caa2856078c8a860b9b95f659c5cc2c1 Kind regards, Remi Gacogne Nuage Labs SAS --- Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.Received on 2014-02-06 These mail archives are generated by hypermail. |
Page updated December 29, 2013.
web site info