Skip to content
  1. Sep 20, 2010
    • Hendrik Visage's avatar
      MacOSX-Framework: updates for Snowleopard · 70a025f3
      Hendrik Visage authored
      1) PPC64 appears to be an 10.5 only supported architecture, so I
      forced 10.5 for 64bit if there is a need for PPC64, else 64bit only
      does x86_64
      
      2) proper "make clean" after every ./configure. fixes a bug where
      subsequent runs the 32bit do not get compiled
      
      3) Added a version numbering curl-$VERSION} rather than the "stock standard" A
      70a025f3
    • Daniel Stenberg's avatar
      RELEASE-NOTES: synced with 5fcc4332 · 95e230c5
      Daniel Stenberg authored
      Removed the duplicate entry of Kamil in the credits.
      95e230c5
    • Daniel Stenberg's avatar
      configure: don't enable RTMP if the lib detect fails · 5fcc4332
      Daniel Stenberg authored
      librtmp is often statically linked and using sub dependencies like
      OpenSSL, so we need to make sure we can actually link with it properly
      before enabling it. Otherwise we easily end up trying to link with a
      RTMP lib that fails.
      5fcc4332
    • Daniel Stenberg's avatar
      TODO: added 8.4 non-gcrypt under GnuTLS · 7d84113e
      Daniel Stenberg authored
      We must not assume gcrypt just because of GnuTLS
      7d84113e
    • Daniel Stenberg's avatar
      configure: check for gcrypt if using GnuTLS · f3df524b
      Daniel Stenberg authored
      1 - libcurl assumes that there are gcrypt functions available when
      GnuTLS is.
      
      2 - GnuTLS can be built to use libnettle instead as crypto library,
      which breaks assumption (1)
      
      This change makes configure make sure that if GnuTLS is requested and
      detected, it also makes sure that gcrypt is present or it errors
      out. This is mostly a way to make the user more aware of this flaw, the
      correct fix would be to detect which crypto layer that is in use and
      adapt our code to use that instead of blindly assuming gcrypt.
      
      Reported by: Michal Gorny
      Bug: http://curl.haxx.se/bug/view.cgi?id=3071038
      f3df524b
  2. Sep 18, 2010
  3. Sep 17, 2010
    • Mauro Iorio's avatar
      LDAP: Support for tunnelling queries through HTTP proxy · c59dba33
      Mauro Iorio authored
      As of curl-7.21.1 tunnelling ldap queries through HTTP Proxies is not
      supported. Actually if --proxytunnel command-line option (or equivalent
      CURLOPT_HTTPPROXYTUNNEL) is used for ldap queries like
      ldap://ldap.my.server.com/... You are unable to successfully execute the
      query. In facts ldap_*_bind is executed directly against the ldap server
      and proxy is totally ignored. This is true for both openLDAP and
      Microsoft LDAP API.
      
      Step to reproduce the error:
      Just launch "curl --proxytunnel --proxy 192.168.1.1:8080
      ldap://ldap.my.server.com/dc=... "
      
      This fix adds an invocation to Curl_proxyCONNECT against the provided
      proxy address and on successful "CONNECT" it tunnels ldap query to the
      final ldap server through the HTTP proxy. As far as I know Microsoft
      LDAP APIs don't permit tunnelling in any way so the patch provided is
      for OpenLDAP only.  The patch has been developed against OpenLDAP 2.4.23
      and has been tested with Microsoft ISA Server 2006 and works properly
      with basic, digest and NTLM authentication.
      c59dba33
    • Daniel Stenberg's avatar
      timeout: use the correct start value as offset · a76f852c
      Daniel Stenberg authored
      Rodric provide an awesome recipe that proved libcurl didn't timeout at
      the requested time - it instead often timed out at [connect time] +
      [timeout time] instead of the documented and intended [timeout time]
      only. This bug was due to the code using the wrong base offset when
      comparing against "now". I could also take the oppurtinity to simplify
      the code by properly using of the generic help function for this:
      Curl_timeleft.
      
      Reported by: Rodric Glaser
      Bug: http://curl.haxx.se/bug/view.cgi?id=3061535
      a76f852c
    • Daniel Stenberg's avatar
      Curl_timeleft: avoid returning "no timeout" by mistake · 3880dd37
      Daniel Stenberg authored
      As this function uses return code 0 to mean that there is no timeout, it
      needs to check that it doesn't return a time left value that is exactly
      zero. It could lead to libcurl doing an extra 1000 ms select() call and
      thus not timing out as accurately as it should.
      
      I fell over this bug when working on the bug 3061535 but this fix does
      not correct that problem alone, although this is a problem that needs to
      be fixed.
      
      Reported by: Rodric Glaser
      Bug: http://curl.haxx.se/bug/view.cgi?id=3061535
      3880dd37
  4. Sep 16, 2010
  5. Sep 15, 2010
  6. Sep 14, 2010
    • James Bursa's avatar
      getinmemory: make the example easier to follow · fbefd816
      James Bursa authored
      1. Remove the comment warning that it's "not been verified to work". It
         works with no problems in my testing.
      
      2. Remove 2 unnecessary includes.
      
      3. Remove the myrealloc(). Initialize chunk.memory with malloc() instead
         of NULL. The comments for these two parts contradicted each other.
      
      4. Handle out of memory from realloc() instead of continuing.
      
      5. Print a brief status message at the end.
      fbefd816
    • Daniel Stenberg's avatar
      multi: don't do extra expire calls for the connection · 296b246b
      Daniel Stenberg authored
      The timeout is set for the connect phase already at the start of the
      request so we should not add a new one, and we MUST not set expire to 0
      as that will remove any other potentially existing timeouts.
      296b246b
  7. Sep 12, 2010
  8. Sep 09, 2010
  9. Sep 08, 2010
  10. Sep 07, 2010
  11. Sep 06, 2010
  12. Sep 05, 2010
  13. Sep 03, 2010
  14. Sep 02, 2010
  15. Sep 01, 2010