Skip to content
  1. Jun 24, 2010
    • Daniel Stenberg's avatar
      multi_socket: re-use of same socket without notifying app · 8da56e12
      Daniel Stenberg authored
      When a hostname resolves to multiple IP addresses and the first one
      tried doesn't work, the socket for the second attempt may get dropped on
      the floor, causing the request to eventually time out. The issue is that
      when using kqueue (as on mac and bsd platforms) instead of select, the
      kernel removes the first fd from kqueue when it is closed (in trynextip,
      connect.c:503). Trynextip() then goes on to open a new socket, which
      gets assigned the same number as the one it just closed. Later in
      multi.c, socket_cb is not called because the fd is already in
      multi->sockhash, so the new socket is never added to kqueue.
      
      The correct fix is to ensure that socket_cb is called to remove the fd
      when trynextip() closes the socket, and again to re-add it after
      singleipsocket(). I'm not sure how to cleanly do that, but the attached
      patch works around the problem in an admittedly kludgy way by delaying
      the close to ensure that the newly-opened socket gets a different fd.
      
      Daniel's added comment: I didn't spot a way to easily do a nicer fix so
      I've proceeded with Ben's patch.
      
      Bug: http://curl.haxx.se/bug/view.cgi?id=3017819
      Patch by: Ben Darnell
      8da56e12
    • Pavel Raiskup's avatar
      ftp-wildcard: avoid tight loop when used without any pattern · 0a040789
      Pavel Raiskup authored
      It was broken for URLs like "ftp://example.com/".
      0a040789
  2. Jun 21, 2010
  3. Jun 19, 2010
  4. Jun 18, 2010
  5. Jun 17, 2010
  6. Jun 16, 2010
  7. Jun 10, 2010
  8. Jun 09, 2010
  9. Jun 08, 2010
  10. Jun 07, 2010
  11. Jun 05, 2010
    • Constantine Sapuntzakis's avatar
      OpenSSL: fix spurious SSL connection aborts · a0dd9df9
      Constantine Sapuntzakis authored
      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
    • Yang Tse's avatar
      replace socklen_t with curl_socklen_t · 4724b9d9
      Yang Tse authored
      4724b9d9
  12. Jun 04, 2010