1. 13 Sep, 2014 9 commits
  2. 12 Sep, 2014 4 commits
    • Daniel Stenberg's avatar
      libcurl-tutorial.3: fix GnuTLS link to thread-safety guidelines · 06b27ea2
      Daniel Stenberg authored
      The former link was turned into a 404 at some point.
      
      Reported-By: Askar Safin
      06b27ea2
    • Daniel Stenberg's avatar
      contributors.sh: split list of names at comma · 1b314a85
      Daniel Stenberg authored
      ... to support a list of names provided in a commit message.
      1b314a85
    • Ulrich Telle's avatar
      ntlm: Fixed HTTP proxy authentication when using Windows SSPI · 8ee18228
      Ulrich Telle authored
      Removed ISC_REQ_* flags from calls to InitializeSecurityContext to fix
      bug in NTLM handshake for HTTP proxy authentication.
      
      NTLM handshake for HTTP proxy authentication failed with error
      SEC_E_INVALID_TOKEN from InitializeSecurityContext for certain proxy
      servers on generating the NTLM Type-3 message.
      
      The flag ISC_REQ_CONFIDENTIALITY seems to cause the problem according
      to the observations and suggestions made in a bug report for the
      QT project (https://bugreports.qt-project.org/browse/QTBUG-17322).
      
      Removing all the flags solved the problem.
      
      Bug: http://curl.haxx.se/mail/lib-2014-08/0273.html
      Reported-by: Ulrich Telle
      Assisted-by: Steve Holme, Daniel Stenberg
      8ee18228
    • Ray Satiro's avatar
      newlines: fix mixed newlines to LF-only · 006b61eb
      Ray Satiro authored
      I use the curl repo mainly on Windows with the typical Windows git
      checkout which converts the LF line endings in the curl repo to CRLF
      automatically on checkout. The automatic conversion is not done on files
      in the repo with mixed line endings. I recently noticed some weird
      output with projects/build-openssl.bat that I traced back to mixed line
      endings, so I scanned the repo and there are files (excluding the
      test data) that have mixed line endings.
      
      I used this command below to do the scan. Unfortunately it's not as easy
      as git grep, at least not on Windows. This gets the names of all the
      files in the repo's HEAD, gets each of those files raw from HEAD, checks
      for mixed line endings of both LF and CRLF, and prints the name if
      mixed. I excluded path tests/data/test* because those can have mixed
      line endings if I understand correctly.
      
      for f in `git ls-tree --name-only --full-tree -r HEAD`;
      do if [ -n "${f##tests/data/test*}" ];
          then git show "HEAD:$f" | \
              perl -0777 -ne 'exit 1 if /([^\r]\n.*\r\n)|(\r\n.*[^\r]\n)/';
          if [ $? -ne 0 ];
              then echo "$f";
          fi;
      fi;
      done
      006b61eb
  3. 11 Sep, 2014 2 commits
  4. 10 Sep, 2014 13 commits
  5. 09 Sep, 2014 4 commits
  6. 08 Sep, 2014 6 commits
  7. 07 Sep, 2014 2 commits
    • Daniel Stenberg's avatar
      3963adca
    • Brandon Casey's avatar
      Ensure progress.size_dl/progress.size_ul are always >= 0 · 6beb0eee
      Brandon Casey authored
      
      
      Historically the default "unknown" value for progress.size_dl and
      progress.size_ul has been zero, since these values are initialized
      implicitly by the calloc that allocates the curl handle that these
      variables are a part of.  Users of curl that install progress
      callbacks may expect these values to always be >= 0.
      
      Currently it is possible for progress.size_dl and progress.size_ul
      to by set to a value of -1, if Curl_pgrsSetDownloadSize() or
      Curl_pgrsSetUploadSize() are passed a "size" of -1 (which a few
      places currently do, and a following patch will add more).  So
      lets update Curl_pgrsSetDownloadSize() and Curl_pgrsSetUploadSize()
      so they make sure that these variables always contain a value that
      is >= 0.
      
      Updates test579 and test599.
      
      Signed-off-by: default avatarBrandon Casey <drafnel@gmail.com>
      6beb0eee