#1352 WinSSL times out when uploading and timeout option is set to 0

winssl (3)
Edward Rudd

We are using libcurl (currently 7.29) compiled with WinSSL for our Windows build of the application. We are having a weird issue with where we are receiving a timeout when uploading data and should NOT receive one as we have the CURLOPT_TIMEOUT set to 0 (the default value). when looking through the code in curl_schannel.c there seems to be a condition not handled while uploading the data. the Curl_socket_ready method will return 0 (meaning the write socket is not ready), and instead of trying waiting and trying again, the schannel_send method will simply abort with a timeout error.


  • Daniel Stenberg

    Daniel Stenberg - 2014-04-03
    • assigned_to: Daniel Stenberg
  • Daniel Stenberg

    Daniel Stenberg - 2014-04-03

    Thanks for your report.

    Without a timeout set, there's still a default timeout that is used during connection that seems to be what should be in use in that condition. See Curl_timeleft() in lib/connect.c

    Curl_socket_ready() should then not return (with a zero value) until that timeout has passed so I think the code looks correct.

    If not, can you write a suggested fix that you think makes the logic work better?

    The logic seems to be present pretty much the same even in the latest curl release.

  • Edward Rudd

    Edward Rudd - 2014-04-03

    however this is not occurring during connect, but during upload. So it's not Curl_timeleft that is causing our timeout.

    The line # where we are getting our "timeout" is 780 in curl_schannel.c

    What happens is the user is uploading a screenshot to AWS S3, and gets about 25-30 seconds in and then there's a slight pause for some network reason and curl gives up (because of that what == 0 check) before the users network becomes uncongested.. (these are unfortunately slow clients).

    Right now we are sending out a new beta build that tries to set an explicit timeout of 5 or 10 minutes and seeing if that works around this issue.. If so, then there is definitely something up in L780 in that block that should handle the "no timeout" post-connect case.

  • Edward Rudd

    Edward Rudd - 2014-04-04

    Ok.. It does seem to be a completely different issue the other use is having.

    We did receive verification that switching to an explicit timeout resolves the issue for the user. So, now to figure out how to properly fix the issue.

  • Radu Simionescu

    Radu Simionescu - 2014-05-02

    Shouldn't the preceding call to Curl_timeleft pass a parameter of FALSE (meaning not during connect)?
    The way it's coded right now the sending is cut after the connect timeout, with its 5 minute default if not set to something else.

    Last edit: Radu Simionescu 2014-05-02
    • Daniel Stenberg

      Daniel Stenberg - 2014-05-04

      I think that's spot on, a fix could look like this:

      diff --git a/lib/vtls/curl_schannel.c b/lib/vtls/curl_schannel.c
      index 575b693..64e79e1 100644
      --- a/lib/vtls/curl_schannel.c
      +++ b/lib/vtls/curl_schannel.c
      @@ -763,11 +763,11 @@ schannel_send(struct connectdata *conn, int sockindex,
      long timeleft;
      int what;

         this_write = 0;
      • timeleft = Curl_timeleft(conn->data, NULL, TRUE);
      • timeleft = Curl_timeleft(conn->data, NULL, FALSE);
        if(timeleft < 0) {
        / we already got the timeout /
        failf(conn->data, "schannel: timed out sending data "
        "(bytes sent: %zd)", written);

      ... but as I don't think the original problem mentioned 5 minutes I'm not sure it is the same error...

  • Daniel Stenberg

    Daniel Stenberg - 2014-05-08
    • status: open --> pending-needsinfo
  • Daniel Stenberg

    Daniel Stenberg - 2014-05-08

    I'd be great to get confirmation on this. This change has been pushed and unless someone objects, this report will be closed within shortly as I suspect it is now fixed.

  • Daniel Stenberg

    Daniel Stenberg - 2014-05-15

    Presumed to be fixed, no response, closing.

  • Daniel Stenberg

    Daniel Stenberg - 2014-05-15
    • status: pending-needsinfo --> closed-fixed
  • Edward Rudd

    Edward Rudd - 2014-05-15

    You know, this actually might have fixed our issue. as we restricted our connect timeout to 30s which aligns with how long until we see the "timeout". We'll apply this patch and see if it resolves the issue. (It's been quite hectic lately)


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks