1. 05 11月, 2020 1 次提交
  2. 07 2月, 2017 1 次提交
  3. 03 2月, 2016 1 次提交
  4. 06 8月, 2015 1 次提交
  5. 22 6月, 2010 1 次提交
  6. 17 6月, 2010 1 次提交
  7. 16 6月, 2010 1 次提交
  8. 06 6月, 2010 1 次提交
    • C
      OpenSSL: fix spurious SSL connection aborts · a0dd9df9
      Constantine Sapuntzakis 提交于
      Was seeing spurious SSL connection aborts using libcurl and
      OpenSSL. I tracked it down to uncleared error state on the
      OpenSSL error stack - patch attached deals with that.
      
      Rough idea of problem:
      
      Code that uses libcurl calls some library that uses OpenSSL but
      don't clear the OpenSSL error stack after an error.
      
      ssluse.c calls SSL_read which eventually gets an EWOULDBLOCK from
      the OS. Returns -1 to indicate an error
      
      ssluse.c calls SSL_get_error. First thing, SSL_get_error calls
      ERR_get_error to check the OpenSSL error stack, finds an old
      error and returns SSL_ERROR_SSL instead of SSL_ERROR_WANT_READ or
      SSL_ERROR_WANT_WRITE.
      
      ssluse.c returns an error and aborts the connection
      
      Solution:
      
      Clear the openssl error stack before calling SSL_* operation if
      we're going to call SSL_get_error afterwards.
      
      Notes:
      
      This is much more likely to happen with multi because it's easier
      to intersperse other calls to the OpenSSL library in the same
      thread.
      a0dd9df9
  9. 05 6月, 2010 1 次提交
  10. 04 6月, 2010 1 次提交
    • Y
      Enable OpenLDAP support for cygwin builds. · 43d20d81
      Yang Tse 提交于
      Enable OpenLDAP support for cygwin builds. This support was disabled back
      in 2008 due to incompatibilities between OpenSSL and OpenLDAP headers.
      cygwin's OpenSSL 0.9.8l and OpenLDAP 2.3.43 versions on cygwin 1.5.25
      allow building an OpenLDAP enabled libcurl supporting back to Windows 95.
      
      Remove non-functional CURL_LDAP_HYBRID code and references.
      43d20d81
  11. 03 6月, 2010 1 次提交
  12. 02 6月, 2010 2 次提交
    • Y
      mention last changes · 51248a9b
      Yang Tse 提交于
      51248a9b
    • D
      multi_socket: handles timer inaccuracy better for timeouts · 2c72732e
      Daniel Stenberg 提交于
      Igor Novoseltsev reported a problem with the multi socket API and
      using timeouts and timers. It boiled down to a problem with
      libcurl's use of GetTickCount() interally to figure out the
      current time, while Igor's own application code used another
      function call.
      
      It made his app call the socket API timeout function a bit
      _before_ libcurl would consider the timeout to trigger, and that
      could easily lead to timeouts or stalls in the app. It seems
      GetTickCount() in general often has no better resolution than
      16ms and switching to the alternative function
      QueryPerformanceCounter has its share of problems:
      http://www.virtualdub.org/blog/pivot/entry.php?id=106
      
      We address this problem by simply having libcurl treat timers
      that already has occured or will occur within 40ms subject for
      treatment. I'm confident that there are other implementations and
      operating systems with similarly in accurate timer functions so
      it makes sense to have applied generically and I don't believe we
      sacrifice much by adding a 40ms inaccuracy on these timeouts.
      2c72732e
  13. 28 5月, 2010 2 次提交
  14. 26 5月, 2010 2 次提交
  15. 25 5月, 2010 1 次提交
    • H
      LDAP: properly implemented as a curl_handler · 2e056353
      Howard Chu 提交于
      makes the LDAP code much cleaner, nicer and in general being a
      better libcurl citizen. If a new enough OpenLDAP version is
      detect, the new and shiny lib/openldap.c code is then used
      instead of the old cruft
      
      Code by Howard, minor cleanups by Daniel.
      2e056353
  16. 22 5月, 2010 2 次提交
    • D
      TFTP: send legal timeout value · d17709da
      Daniel Stenberg 提交于
      Eric Mertens posted bug #3003705: when we made TFTP use the
      correct timeout option when sent to the server (fixed May 18th
      2010) it became obvious that libcurl used invalid timeout values
      (300 by default while the RFC allows nothing above 255). While of
      course it is obvious that as TFTP has worked thus far without
      being able to set timeout at all, just removing the setting
      wouldn't make any difference in behavior. I decided to still keep
      it (but fix the problem) as it now actually allows for easier
      (future) customization of the timeout.
      
      (http://curl.haxx.se/bug/view.cgi?id=3003705)
      d17709da
    • D
      TFTP: block id wrap bug fix · 0a29e244
      Daniel Stenberg 提交于
      In a normal expression, doing [unsigned short] + 1 will not wrap
      at 16 bits so the comparisons and outputs were done wrong. I
      added a macro do make sure it gets done right.
      
      Douglas Kilpatrick filed bug report #3004787 about it:
      http://curl.haxx.se/bug/view.cgi?id=3004787
      0a29e244
  17. 21 5月, 2010 1 次提交
  18. 19 5月, 2010 1 次提交
  19. 16 5月, 2010 1 次提交
  20. 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
  21. 13 5月, 2010 1 次提交
  22. 11 5月, 2010 1 次提交
  23. 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
  24. 07 5月, 2010 1 次提交
  25. 06 5月, 2010 1 次提交
  26. 29 4月, 2010 1 次提交
  27. 26 4月, 2010 2 次提交
  28. 25 4月, 2010 1 次提交
  29. 24 4月, 2010 2 次提交
  30. 22 4月, 2010 1 次提交
  31. 20 4月, 2010 1 次提交
  32. 19 4月, 2010 1 次提交