1. 22 5月, 2010 1 次提交
  2. 21 5月, 2010 1 次提交
  3. 19 5月, 2010 1 次提交
  4. 16 5月, 2010 1 次提交
  5. 15 5月, 2010 3 次提交
    • D
      OpenSSL: multi interface handshake could hang · 77cfeadf
      Daniel Stenberg 提交于
      John-Mark Bell filed bug #3000052 that identified a problem (with
      an associated patch) with the OpenSSL handshake state machine
      when the multi interface is used:
      
      Performing an https request using a curl multi handle and using
      select or epoll to wait for events results in a hang. It appears
      that the cause is the fix for bug #2958179, which makes
      ossl_connect_common unconditionally return from the step 2 loop
      when fetching from a multi handle.
      
      When ossl_connect_step2 has completed, it updates
      connssl->connecting_state to ssl_connect_3. ossl_connect_common
      will then return to the caller, as a multi handle is in
      use. Eventually, the client code will call curl_multi_fdset to
      obtain an updated fdset to select or epoll on. For https
      requests, curl_multi_fdset will cause https_getsock to be called.
      https_getsock will only return a socket handle if the
      connecting_state is ssl_connect_2_reading or
      ssl_connect_2_writing.  Therefore, the client will never obtain a
      valid fdset, and thus not drive the multi handle, resulting in a
      hang.
      
      (http://curl.haxx.se/bug/view.cgi?id=3000052)
      77cfeadf
    • D
      changelog: add link to bug report · ea521cf6
      Daniel Stenberg 提交于
      ea521cf6
    • D
      follow redirect: ignore response-body on redirect even if compressed · 7764795c
      Daniel Stenberg 提交于
      Sebastian V reported bug #3000056 identifying a problem with
      redirect following. It showed that when curl followed redirects
      it didn't properly ignore the response body of the 30X response
      if that response was using compressed Content-Encoding!
      
      (http://curl.haxx.se/bug/view.cgi?id=3000056)
      7764795c
  6. 13 5月, 2010 1 次提交
  7. 11 5月, 2010 1 次提交
  8. 08 5月, 2010 1 次提交
    • D
      multi interface: missed storing connection time · adaf8753
      Daniel Stenberg 提交于
      Dirk Manske reported a regression. When connecting with the multi
      interface, there were situations where libcurl wouldn't store
      connect time correctly as it used to (and is documented to) do.
      
      Using his fine sample program we could repeat it, and I wrote up
      test case 573 using that code. The problem does not easily show
      itself using the local test suite though.
      
      The fix, also as suggested by Dirk, is a bit on the ugly side as
      it adds yet another call to Curl_verboseconnect() and setting the
      TIMER_CONNECT time.  That situation is subject for some closer
      inspection in the future.
      adaf8753
  9. 07 5月, 2010 1 次提交
  10. 06 5月, 2010 1 次提交
  11. 29 4月, 2010 1 次提交
  12. 26 4月, 2010 2 次提交
  13. 25 4月, 2010 1 次提交
  14. 24 4月, 2010 2 次提交
  15. 22 4月, 2010 1 次提交
  16. 20 4月, 2010 1 次提交
  17. 19 4月, 2010 1 次提交
  18. 17 4月, 2010 1 次提交
  19. 16 4月, 2010 1 次提交
  20. 15 4月, 2010 1 次提交
  21. 14 4月, 2010 1 次提交
  22. 09 4月, 2010 1 次提交
  23. 06 4月, 2010 1 次提交
  24. 05 4月, 2010 2 次提交
  25. 02 4月, 2010 1 次提交
    • D
      fix SFTP download hang · 49f3160d
      Daniel Stenberg 提交于
      Matt Wixson found and fixed a bug in the SCP/SFTP area where the
      code treated a 0 return code from libssh2 to be the same as
      EAGAIN while in reality it isn't. The problem caused a hang in
      SFTP transfers from a MessageWay server.
      49f3160d
  26. 29 3月, 2010 1 次提交
  27. 28 3月, 2010 1 次提交
    • B
      allow user+password in the URL for all protocols · 0eda142e
      Ben Greear 提交于
      Ben Greear brought a patch that from now on allows all protocols
      to specify name and user within the URL, in the same manner HTTP
      and FTP have been allowed to in the past - although far from all
      of the libcurl supported protocols actually have that feature in
      their URL definition spec.
      0eda142e
  28. 27 3月, 2010 1 次提交
  29. 25 3月, 2010 1 次提交
    • B
      fix: timeout after last data chunk was handled · 05632d5d
      Bob Richmond 提交于
      Bob Richmond: There's an annoying situation where libcurl will
      read new HTTP response data from a socket, then check if it's a
      timeout if one is set. If the last packet received constitutes
      the end of the response body, libcurl still treats it as a
      timeout condition and reports a message like:
      
      "Operation timed out after 3000 milliseconds with 876 out of 876
      bytes received"
      
      It should only a timeout if the timer lapsed and we DIDN'T
      receive the end of the response body yet.
      05632d5d
  30. 24 3月, 2010 3 次提交
  31. 23 3月, 2010 3 次提交
    • D
      chunked-encoding with Content-Length: header problem · 7fd32ce7
      Daniel Stenberg 提交于
      Akos Pasztory filed debian bug report #572276
      http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572276
      mentioning a problem with a resource that returns chunked-encoded
      _and_ with a Content-Length and libcurl failed to properly ignore
      the latter information.
      7fd32ce7
    • D
      delayed easy handle kill caused double Curl_close() call · 2a94293e
      Daniel Stenberg 提交于
      Hauke Duden provided an example program that made the multi
      interface crash.  His example simply used the multi interface and
      did first one FTP transfer and after completion it used a second
      easy handle and did another FTP transfer on the same FTP server.
      
      This triggered a bug in the "delayed easy handle kill" system
      that curl uses: when an FTP connection is left alive it must keep
      an easy handle around internally - only for the purpose of having
      an easy handle when it later disconnects it. The code assumed
      that when the easy handle was removed and an internal reference
      was made, that version could be killed later on when a new easy
      handle came using the same connection. This was wrong as Hauke's
      example showed that the removed handle wasn't killed for real
      until later. This caused a double close attempt => segfault.
      2a94293e
    • D
      d4cd5411