If Makefile.am uses CRLF, buildconf in a Windows checkout fails with:
".ibtoolize: error: AC_CONFIG_MACRO_DIRS([m4]) conflicts with
ACLOCAL_AMFLAGS=-I m4"
- If SSL_get_error is called but no extended error detail is available
then show that SSL_ERROR_* as a string.
Prior to this change there was some inconsistency in that case: the
SSL_ERROR_* code may or may not have been shown, or may have been shown
as unknown even if it was known.
Ref: https://github.com/curl/curl/issues/1300
Closes https://github.com/curl/curl/pull/1348
Note that for some reason there is this warning (that also exists with
autotools, added since curl-7_15_1-94-ga718cb05f):
docs/libcurl/curl_multi_socket_all.3:1: can't open `man3/curl_multi_socket.3': No such file or directory
Additionally, adjust the roffit --mandir option to support creating
links when doing out-of-tree builds.
Ref: https://github.com/curl/curl/pull/1288
Also make Perl mandatory to allow building the docs.
While CMakeLists.txt could probably read the list of manual pages from
Makefile.am, actually putting those in CMakeLists.txt is cleaner so that
is what is done here.
Fixes#1230
Ref: https://github.com/curl/curl/pull/1288
For easier sharing with CMake. The contents were reformatted to use
two-space indent and expanded tabs (matching lib/Makefile.common).
Ref: https://github.com/curl/curl/pull/1288
- Show the HTTPS-proxy options on CURLE_SSL_CACERT if libcurl was built
with HTTPS-proxy support.
Prior to this change those options were shown only if an HTTPS-proxy was
specified by --proxy, but that did not take into account environment
variables such as http_proxy, https_proxy, etc. Follow-up to e1187c4.
Bug: https://github.com/curl/curl/issues/1331
Reported-by: Nehal J Wani
Depend on the known behaviour of URLs for nonexistent files rather than
the undefined behaviour of URLs for directories (which fails on Windows).
The test isn't about file: URLs at all, so the URL used doesn't really
matter.
If a % ended the statement, the string's trailing NUL would be skipped
and memory past the end of the buffer would be accessed and potentially
displayed as part of the --write-out output. Added tests 1440 and 1441
to check for this kind of condition.
Reported-by: Brian Carpenter
- Add new option CURLOPT_SUPPRESS_CONNECT_HEADERS to allow suppressing
proxy CONNECT response headers from the user callback functions
CURLOPT_HEADERFUNCTION and CURLOPT_WRITEFUNCTION.
- Add new tool option --suppress-connect-headers to expose
CURLOPT_SUPPRESS_CONNECT_HEADERS and allow suppressing proxy CONNECT
response headers from --dump-header and --include.
Assisted-by: Jay Satiro
Assisted-by: CarloCannas@users.noreply.github.com
Closes https://github.com/curl/curl/pull/783
A client MUST ignore any Content-Length or Transfer-Encoding header
fields received in a successful response to CONNECT.
"Successful" described as: 2xx (Successful). RFC 7231 4.3.6
Prior to this change such a case would cause an error.
In some ways this bug appears to be a regression since c50b878. Prior to
that libcurl may have appeared to function correctly in such cases by
acting on those headers instead of causing an error. But that behavior
was also incorrect.
Bug: https://github.com/curl/curl/issues/1317
Reported-by: mkzero@users.noreply.github.com
