Skip to content
  1. Jan 14, 2007
  2. Jan 13, 2007
  3. Jan 05, 2007
  4. Jan 03, 2007
  5. 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
  6. Dec 29, 2006
  7. Dec 25, 2006
  8. Dec 22, 2006
  9. 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
  10. Dec 16, 2006
  11. 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
  12. 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
  13. Dec 05, 2006
  14. Dec 01, 2006
  15. 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
  16. Nov 24, 2006
  17. Nov 21, 2006
  18. Nov 18, 2006
  19. Nov 13, 2006
  20. Nov 09, 2006
  21. Nov 08, 2006
  22. Nov 07, 2006
  23. Nov 03, 2006
  24. Nov 02, 2006
  25. Oct 30, 2006
  26. Oct 29, 2006
  27. Oct 25, 2006
    • Daniel Stenberg's avatar
      Fixed CURLOPT_FAILONERROR to return CURLE_HTTP_RETURNED_ERROR even for the · cde5e35d
      Daniel Stenberg authored
      case when 401 or 407 are returned, *IF* no auth credentials have been given.
      The CURLOPT_FAILONERROR option is not possible to make fool-proof for 401
      and 407 cases when auth credentials is given, but we've now covered this
      somewhat more.
      
      You might get some amounts of headers transferred before this situation is
      detected, like for when a "100-continue" is received as a response to a
      POST/PUT and a 401 or 407 is received immediately afterwards.
      
      Added test 281 to verify this change.
      cde5e35d
  28. Oct 21, 2006