Skip to content
  1. Feb 16, 2007
  2. Feb 13, 2007
  3. Feb 12, 2007
  4. Feb 05, 2007
    • Daniel Stenberg's avatar
      - Michael Wallner provided a patch that adds support for CURLOPT_TIMEOUT_MS · 91386937
      Daniel Stenberg authored
        and CURLOPT_CONNECTTIMEOUT_MS that, as their names should hint, do the
        timeouts with millisecond resolution instead. The only restriction to that
        is the alarm() (sometimes) used to abort name resolves as that uses full
        seconds. I fixed the FTP response timeout part of the patch.
      
        Internally we now count and keep the timeouts in milliseconds but it also
        means we multiply set timeouts with 1000. The effect of this is that no
        timeout can be set to more than 2^31 milliseconds (on 32 bit systems), which
        equals 24.86 days.  We probably couldn't before either since the code did
        *1000 on the timeout values on several places already.
      91386937
    • Yang Tse's avatar
  5. Feb 03, 2007
  6. Feb 02, 2007
  7. Jan 30, 2007
  8. Jan 29, 2007
  9. Jan 28, 2007
  10. Jan 25, 2007
  11. Jan 23, 2007
  12. Jan 16, 2007
  13. Jan 14, 2007
  14. Jan 13, 2007
  15. Jan 05, 2007
  16. Jan 03, 2007
  17. Jan 02, 2007
    • Daniel Stenberg's avatar
      - Victor Snezhko helped us fix bug report #1603712 · 0682d25d
      Daniel Stenberg authored
        (http://curl.haxx.se/bug/view.cgi?id=1603712) (known bug #36) --limit-rate
        (CURLOPT_MAX_SEND_SPEED_LARGE and CURLOPT_MAX_RECV_SPEED_LARGE) are broken
        on Windows (since 7.16.0, but that's when they were introduced as previous
        to that the limiting logic was made in the application only and not in the
        library). It was actually also broken on select()-based systems (as apposed
        to poll()) but we haven't had any such reports. We now use select(), Sleep()
        or delay() properly to sleep a while without waiting for anything input or
        output when the rate limiting is activated with the easy interface.
      0682d25d
  18. Dec 29, 2006
  19. Dec 25, 2006
  20. Dec 22, 2006
  21. Dec 21, 2006
    • Daniel Stenberg's avatar
      Robson Braga Araujo reported bug #1618359 · 89ab5f43
      Daniel Stenberg authored
      (http://curl.haxx.se/bug/view.cgi?id=1618359) and subsequently provided a
      patch for it: when downloading 2 zero byte files in a row, curl 7.16.0
      enters an infinite loop, while curl 7.16.1-20061218 does one additional
      unnecessary request.
      
      Fix: During the "Major overhaul introducing http pipelining support and
      shared connection cache within the multi handle." change, headerbytecount
      was moved to live in the Curl_transfer_keeper structure. But that structure
      is reset in the Transfer method, losing the information that we had about
      the header size. This patch moves it back to the connectdata struct.
      89ab5f43
  22. Dec 16, 2006
  23. Dec 11, 2006
    • Daniel Stenberg's avatar
      Alexey Simak found out that when doing FTP with the multi interface and · 88c8d72a
      Daniel Stenberg authored
      something went wrong like it got a bad response code back from the server,
      libcurl would leak memory. Added test case 538 to verify the fix.
      
      I also noted that the connection would get cached in that case, which
      doesn't make sense since it cannot be re-use when the authentication has
      failed. I fixed that issue too at the same time, and also that the path
      would be "remembered" in vain for cases where the connection was about to
      get closed.
      88c8d72a
  24. Dec 06, 2006
    • Daniel Stenberg's avatar
      Sebastien Willemijns reported bug #1603712 · 840e796a
      Daniel Stenberg authored
      (http://curl.haxx.se/bug/view.cgi?id=1603712) which is about connections
      getting cut off prematurely when --limit-rate is used. While I found no such
      problems in my tests nor in my reading of the code, I found that the
      --limit-rate code was severly flawed (since it was moved into the lib, since
      7.15.5) when used with the easy interface and it didn't work as documented so
      I reworked it somewhat and now it works for my tests.
      840e796a
  25. Dec 05, 2006
  26. Dec 01, 2006
  27. Nov 25, 2006
    • Daniel Stenberg's avatar
      Venkat Akella found out that libcurl did not like HTTP responses that simply · da58d03f
      Daniel Stenberg authored
      responded with a single status line and no headers nor body. Starting now, a
      HTTP response on a persistent connection (i.e not set to be closed after the
      response has been taken care of) must have Content-Length or chunked
      encoding set, or libcurl will simply assume that there is no body.
      
      To my horror I learned that we had no less than 57(!) test cases that did bad
      HTTP responses like this, and even the test http server (sws) responded badly
      when queried by the test system if it is the test system. So although the
      actual fix for the problem was tiny, going through all the newly failing test
      cases got really painful and boring.
      da58d03f