curl's project page on


cURL > Mailing List > Monthly Index > Single Mail

curl-tracker Archives

[curl:bugs] #1334 Timeout issue in code handling 100-continue

From: Daniel Stenberg <>
Date: Thu, 06 Feb 2014 22:22:37 +0000

- **status**: open --> closed-fixed
- **assigned_to**: Daniel Stenberg

** [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
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):
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:
Kind regards,
Remi Gacogne
Nuage Labs SAS
Sent from because is subscribed to
To unsubscribe from further messages, a project admin can change settings at  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.

donate! Page updated December 29, 2013.
web site info

File upload with ASP.NET