Age | Commit message (Collapse) | Author |
|
... even when there's no protocol specific handler setup.
Bug: https://curl.haxx.se/mail/lib-2018-05/0062.html
Reported-by: Sean Miller
Closes #2600
|
|
Closes #2102
|
|
Closes #2588
|
|
using -DCMAKE_DEBUG_POSTFIX explicitly
fixes #2121, obsoletes #2384
|
|
When given a prefix, the $PREFIX_OPENSSL/lib/openssl.pc or
$PREFIX_OPENSSL/include/openssl/ssl.h files must be present or cause an
error. Helps users detect when giving configure the wrong path.
Reported-by: Oleg Pudeyev
Assisted-by: Per Malmberg
Fixes #2580
|
|
This avoids appending error data to already existing good data.
Test 92 is updated to match this change.
New test 1156 checks all combinations of --range/--resume, --fail,
Content-Range header and http status code 200/416.
Fixes #1163
Reported-By: Ithubg on github
Closes #2578
|
|
|
|
follow-up to mistake in 6876ccf90b4
|
|
OpenSSL has supported --cacert for ages, always accepting LF-only line
endings ("Unix line endings") as well as CR/LF line endings ("Windows
line endings").
When we introduced support for --cacert also with Secure Channel (or in
cURL speak: "WinSSL"), we did not take care to support CR/LF line
endings, too, even if we are much more likely to receive input in that
form when using Windows.
Let's fix that.
Happily, CryptQueryObject(), the function we use to parse the ca-bundle,
accepts CR/LF input already, and the trailing LF before the END
CERTIFICATE marker catches naturally any CR/LF line ending, too. So all
we need to care about is the BEGIN CERTIFICATE marker. We do not
actually need to verify here that the line ending is CR/LF. Just
checking for a CR or an LF is really plenty enough.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Closes https://github.com/curl/curl/pull/2592
|
|
|
|
|
|
Closes #2573
|
|
... and unify the source code to adhere.
Closes #2563
|
|
It is enabled by default, so --no-styled-output will switch off the
detection/use of bold headers.
Closes #2538
|
|
The feature is only enabled if the output is believed to be a tty.
-J: There's some minor differences and improvements in -J handling, as
now J should work with -i and it actually creates a file first using the
initial name and then *renames* that to the one found in
Content-Disposition (if any).
-i: only shows headers for HTTP transfers now (as documented).
Previously it would also show for pieces of the transfer that were HTTP
(for example when doing FTP over a HTTP proxy).
-i: now shows trailers as well. Previously they were not shown at all.
--libcurl: the CURLOPT_HEADER is no longer set, as the header output is
now done in the header callback.
|
|
... instead of exeucting code to get the size. Removes the use of
LD_LIBRARY_PATH for this.
Fixes #2586
Closes #2589
Reported-by: Bernhard Walle
|
|
... and export LD_LIBRARY_PATH properly. This is a follow-up from
2d4c215.
Fixes #2586
Reported-by: Bernhard Walle
|
|
Reported-by: bsammon on github
Fixes #2590
|
|
The previous limit of 5 can still end up in situation that takes a very
long time and consumes a lot of CPU.
If there is still a rare use case for this, a user can provide their own
fnmatch callback for a version that allows a larger set of wildcards.
This commit was triggered by yet another OSS-Fuzz timeout due to this.
Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8369
Closes #2587
|
|
follow-up to e05ad5d
|
|
...as there's also a version 2.
Closes #2579
|
|
This example was changed in ce2140a8c1 to use the new microsecond based
getinfo option. This change makes it conditionally keep using the older
option so that the example still builds with older libcurl versions.
Closes #2584
|
|
follow-up to d9e92fd9fd1d
|
|
Provide a set of new timers that return the time intervals using integer
number of microseconds instead of floats.
The new info names are as following:
CURLINFO_APPCONNECT_TIME_T
CURLINFO_CONNECT_TIME_T
CURLINFO_NAMELOOKUP_TIME_T
CURLINFO_PRETRANSFER_TIME_T
CURLINFO_REDIRECT_TIME_T
CURLINFO_STARTTRANSFER_TIME_T
CURLINFO_TOTAL_TIME_T
Closes #2495
|
|
... previously it only used the max setting if a TLS version was also
explicitly asked for.
Reported-by: byte_bucket
Fixes #2571
Closes #2572
|
|
|
|
The warning flag leads e.g. Sun Studio compiler to bail out.
Closes #2576
|
|
|
|
|
|
.. because original MinGW and old compilers do not have the Windows API
definitions needed to support manual verification.
|
|
Original MinGW targets Windows 2000 by default, which lacks some APIs and
definitions for this feature. Disable it if these APIs are not available.
Closes https://github.com/curl/curl/pull/2522
|
|
|
|
|
|
The HTML files are long gone from the dist, now remove the last HTML
file pointing to those missing files.
d
|
|
Closes #2570
|
|
|
|
Reported-by: Rikard Falkeborn
Bug: #2560
Closes #2569
|
|
Fixes gcc-8 picky compiler warnings
Reported-by: Rikard Falkeborn
Bug: #2560
Closes #2568
|
|
... and remove the github markdown syntax so that it renders better on
the web site. Also, don't use back-ticks inlined to allow the CSS to
highlight source code better.
|
|
Closes #2561
|
|
|
|
|
|
|
|
|
|
|
|
When there's an upload in progress, make sure to wait for the socket to
become writable.
Detected-by: steini2000 on github
Bug: #2520
Closes #2567
|
|
Response data for a handle with a large buffer might be cached and then
used with the "closure" handle when it has a smaller buffer and then the
larger cache will be copied and overflow the new smaller heap based
buffer.
Reported-by: Dario Weisser
CVE: CVE-2018-1000300
Bug: https://curl.haxx.se/docs/adv_2018-82c2.html
|
|
... leaving the k->str could lead to buffer over-reads later on.
CVE: CVE-2018-1000301
Assisted-by: Max Dymond
Detected by OSS-Fuzz.
Bug: https://curl.haxx.se/docs/adv_2018-b138.html
Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7105
|
|
RFC 6265 section 4.2.1 does not set restrictions on cookie names.
This is a follow-up to commit 7f7fcd0.
Also explicitly check proper syntax of cookie name/value pair.
New test 1155 checks that cookie names are not reserved words.
Reported-By: anshnd at github
Fixes #2564
Closes #2566
|
|
Assisted-by: Max Dymond
Detected by OSS-Fuzz
Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8245
|