Somehow I didn't include the amended version of the previous fix. This
is the missing piece.

Pointed-out-by: Viktor Szakats

Significantly enhances upload performance on modern Windows versions.

Bug: https://curl.haxx.se/mail/lib-2018-07/0080.html
Closes #2762
Fixes #2224

This allows the use of PKCS#11 URI for certificates and keys without
setting the corresponding type as "ENG" and the engine as "pkcs11"
explicitly. If a PKCS#11 URI is provided for certificate, key,
proxy_certificate or proxy_key, the corresponding type is set as "ENG"
if not provided and the engine is set to "pkcs11" if not provided.

Acked-by: Nikos Mavrogiannopoulos
Closes #2333

Use standard CMake variable BUILD_SHARED_LIBS instead of introducing
custom option CURL_STATICLIB.

Use '-DBUILD_SHARED_LIBS=%SHARED%' in appveyor.yml.

Reviewed-by: Sergei Nikulov
Closes #2755

Closes #2753

Reviewed-by: Jakub Zakrzewski
Reviewed-by: Sergei Nikulov
Closes #2753

... as building on 10.13.x before 10.13.4 leads to link errors.

Assisted-by: Nick Zitzmann
Fixes #2835
Closes #2845

Since it will slip and the version is the important part there, not the
date.

This restores the ability to build a static lib with
--disable-symbol-hiding to keep non-curl_ symbols.

Researched-by: Dan Fandrich
Reported-by: Ran Mozes
Fixes #2830
Closes #2831

addresses is only used in an infof call, which is a macro expanding to
nothing if CURL_DISABLE_VERBOSE_STRINGS is set.

Turns out that since we're using the native fnmatch function now when
available, and they simply disagree on a huge number of test patterns
that make it hard to test this function like this...

Fixes #2825

Follow-up to 09e401e0. The SMB protocol handler needs to use its
doing function too, which requires smb_do() to not mark itself as
done...

Closes #2822

Closes #2818

This change fixes a regression where redirect body would needlessly be
decompressed even though it was to be ignored anyway. As it happens this
causes secondary issues since there appears to be a bug in apache2 that
it in certain conditions generates a corrupt zlib response. The
regression was created by commit:
dbcced8e

Discovered-by: Harry Sintonen
Closes #2798

Regression introduced in 7.61.0

Reported-by: Thomas Klausner
Fixes #2783
Closes #2813

Fixes #2801
Closes #2812

Reported-by: Andrei Virtosu
Fixes #2800
Closes #2809

... by making sure connection related data (->share) is stored in the
connection and not in the easy handle.

Detected by OSS-fuzz
Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9369
Fixes #2769
Closes #2810

... to make sure the examples are all checked.

Closes #2811

Closes https://github.com/curl/curl/pull/2808

Ignore the user-agent line.
Pointed-out-by: Marcel Raad

Closes #2793

Let's call it disassociate instead of disconnect since the latter term
is used so much for (TCP) connections already.

Verifies bugfix #2797

The curl binary would crash if the -H command line option was given a
filename to read using the @filename syntax but that file was empty.

Closes #2797

Bug: https://curl.haxx.se/mail/archive-2018-07/0015.html
Reported-by: Jeffrey Walton
Closes #2795

Closes #2804

Closes #2794

The statement, “The application does not have to keep the string around
after setting this option,” appears to be indented under the RTMP
paragraph. It actually applies to all protocols, not just RTMP.
Eliminate the extra indentation.

Closes #2788

For compatibility with `fwrite`, the `CURLOPT_WRITEFUNCTION` callback is
passed two `size_t` parameters which, when multiplied, designate the
number of bytes of data passed in. In practice, CURL always sets the
first parameter (`size`) to 1.

This practice is also enshrined in documentation and cannot be changed
in future. The documentation states that the default callback is
`fwrite`, which means `fwrite` must be a suitable function for this
purpose. However, the documentation also states that the callback must
return the number of *bytes* it successfully handled, whereas ISO C
`fwrite` returns the number of items (each of size `size`) which it
wrote. The only way these numbers can be equal is if `size` is 1.

Since `size` is 1 and can never be changed in future anyway, document
that fact explicitly and let users rely on it.

Closes #2787

RNG structure must be freed by call to FreeRng after its use in
Curl_cyassl_random. This call fixes Valgrind failures when running the
test suite with wolfSSL.

Closes #2784

This fixes a memory leak when CURLOPT_LOGIN_OPTIONS is used, together with
connection reuse.

I found this with oss-fuzz on GDAL and curl master:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9582
I couldn't reproduce with the oss-fuzz original test case, but looking
at curl source code pointed to this well reproducable leak.

Closes #2790

In the current version, VERSION_GREATER_THAN_EQUAL 6.3 will return false
when run on windows 10.0. This patch addresses that error.

Closes https://github.com/curl/curl/pull/2792

So far, the code tries to pick an authentication method only if
user/password credentials are available, which is not the case for
Bearer authentictation...

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Closes #2754

The Bearer authentication was added to cURL 7.61.0, but there is a
problem: if CURLAUTH_ANY is selected, and the server supports multiple
authentication methods including the Bearer method, we strongly prefer
that latter method (only CURLAUTH_NEGOTIATE beats it), and if the Bearer
authentication fails, we will never even try to attempt any other
method.

This is particularly unfortunate when we already know that we do not
have any Bearer token to work with.

Such a scenario happens e.g. when using Git to push to Visual Studio
Team Services (which supports Basic and Bearer authentication among
other methods) and specifying the Personal Access Token directly in the
URL (this aproach is frequently taken by automated builds).

Let's make sure that we have a Bearer token to work with before we
select the Bearer authentication among the available authentication
methods.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Closes #2754