Set HAVE_DES_SET_ODD_PARITY when using OpenSSL/BoringSSL as native Windows builds don't use the autoconf tools.
It isn't always clear to the user which options that cause the HTTP methods to conflict so by spelling them out it should hopefully be easier to understand why curl complains.
"Explicit null dereferenced (FORWARD_NULL)" Coverity CID 1317366
- Add new option CURLOPT_DEFAULT_PROTOCOL to allow specifying a default protocol for schemeless URLs. - Add new tool option --proto-default to expose CURLOPT_DEFAULT_PROTOCOL. In the case of schemeless URLs libcurl will behave in this way: When the option is used libcurl will use the supplied default. When the option is not used, libcurl will follow its usual plan of guessing from the hostname and falling back to 'http'.
... so improve the #ifdefs for using our local implementation.
Since boringssl brought back DES_set_odd_parity again, it cannot be used to differentiate from boringssl. Using the OPENSSL_IS_BORINGSSL define seems better anyway. URL: https://android.googlesource.com/platform/external/curl/+/f551028d5caab29d4b4a4ae8c159c76c3cfd4887%5E!/ Original-patch-by: Bertrand Simonnet Closes #393
... since boringssl moved the former ones and the check started to fail. URL: https://android.googlesource.com/platform/external/curl/+/f551028d5caab29d4b4a4ae8c159c76c3cfd4887%5E!/ Original-patch-by: Bertrand Simonnet
If strict certificate checking is disabled (CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST are disabled) do not fail if the server doesn't present a certificate at all. Closes #392
The multi state machine would otherwise go into the DO_MORE state after DO, even for the case when the FTP state machine had already performed those duties, which caused libcurl to get stuck in that state and fail miserably. This occured for for active ftp uploads. Reported-by: Patricia Muscalu