Age | Commit message (Collapse) | Author |
|
- Allow missing queries, don't return NO_MEMORY error in such a case.
It is acceptable for there to be no specified query string, for example:
curl ldap://ldap.forumsys.com
A regression bug in 1b443a7 caused this issue.
This is a partial fix for #4261.
Bug: https://github.com/curl/curl/issues/4261#issuecomment-525543077
Reported-by: Jojojov@users.noreply.github.com
Analyzed-by: Samuel Surtees
Closes https://github.com/curl/curl/pull/4467
|
|
Closes https://github.com/curl/curl/pull/4460
|
|
Closes #4457
|
|
The second argument is really a 'bool' so use that and pass in TRUE/FALSE
to make it clear.
Closes #4455
|
|
To make sure that the HTTP/2 state is initialized correctly for
duplicated handles. It would otherwise easily generate "spurious"
PRIORITY frames to get sent over HTTP/2 connections when duplicated easy
handles were used.
Reported-by: Daniel Silverstone
Fixes #4303
Closes #4442
|
|
Follow-up from 2c20109a9b5d04
Added test 663 to verify.
Reported by OSS-Fuzz
Bug: https://crbug.com/oss-fuzz/17954
Closes #4453
|
|
This fix removes a use after free which can be triggered by
the internal cookie fuzzer, but otherwise is probably
impossible to trigger from an ordinary application.
The following program reproduces it:
curl_global_init(CURL_GLOBAL_DEFAULT);
CURL* handle=curl_easy_init();
CookieInfo* info=Curl_cookie_init(handle,NULL,NULL,false);
curl_easy_setopt(handle, CURLOPT_COOKIEJAR, "/dev/null");
Curl_flush_cookies(handle, true);
Curl_cookie_cleanup(info);
curl_easy_cleanup(handle);
curl_global_cleanup();
This was found through fuzzing.
Closes #4454
|
|
Closes #4011
|
|
... to make it handle for example (RFC violating) embeded spaces.
Reported-by: momala454 on github
Fixes #4445
Closes #4447
|
|
|
|
Closes #4410
|
|
Unknown content-encoding would get returned as CURLE_WRITE_ERROR if the
response is chunked-encoded.
Reported-by: Ilya Kosarev
Fixes #4310
Closes #4449
|
|
The loop doesn't need to be executed without a file argument.
Closes https://github.com/curl/curl/pull/4444
|
|
`dest` is only used with `ENABLE_IPV6`.
Closes https://github.com/curl/curl/pull/4444
|
|
Closes https://github.com/curl/curl/pull/4444
|
|
As mandated by the spec. Test 1654 is extended to verify.
Closes #4443
|
|
|
|
The 'share object' only sets the storage area for cookies. The "cookie
engine" still needs to be enabled or activated using the normal cookie
options.
This caused the curl command line tool to accidentally use cookies
without having been told to, since curl switched to using shared cookies
in 7.66.0.
Test 1166 verifies
Updated test 506
Fixes #4429
Closes #4434
|
|
|
|
Closes #4428
|
|
Closes https://github.com/curl/curl/pull/4425
|
|
|
|
|
|
This reverts commit 2f036a72d543e96128bd75cb0fedd88815fd42e2.
|
|
Closes #4423
|
|
Instead of showing the somewhat nonsensical errno number, use strerror()
to provide a more relatable error message.
Closes #4411
|
|
Prior to this change non-ssl/non-ssh connections that were reused set
TIMER_APPCONNECT [1]. Arguably that was incorrect since no SSL/SSH
handshake took place.
[1]: TIMER_APPCONNECT is publicly known as CURLINFO_APPCONNECT_TIME in
libcurl and %{time_appconnect} in the curl tool. It is documented as
"the time until the SSL/SSH handshake is completed".
Reported-by: Marcel Hernandez
Ref: https://github.com/curl/curl/issues/3760
Closes https://github.com/curl/curl/pull/3773
|
|
- convert some of them to H3BUF() calls to infof()
- remove some of them completely
- made DEBUG_HTTP3 defined only if CURLDEBUG is set for now
Closes #4421
|
|
Closes #4403
|
|
|
|
Follow-up to d176a2c7e5
|
|
The parser would check for a query part before fragment, which caused it
to do wrong when the fragment contains a question mark.
Extended test 1560 to verify.
Reported-by: Alex Konev
Fixes #4412
Closes #4413
|
|
As libcurl now uses these 2 system functions, wrappers are needed on os400
to convert returned AF_UNIX sockaddrs to ascii.
This is a follow-up to commit 7fb54ef.
See also #4037.
Closes #4214
|
|
Casing mistake in Curl_raw_tolower 'X' wasn't lowercased as 'x' prior to
this change.
Follow-up to 0023fce which added the function several days ago.
Ref: https://github.com/curl/curl/pull/4401#discussion_r327396546
Closes https://github.com/curl/curl/pull/4408
|
|
PVS-Studio warning
Fixes #4402
|
|
PVS-Studio warning
Fixes #4402
|
|
PVS-Studio warning
Fixed #4402
|
|
PVS-Studio warning
Fixes #4402
|
|
PVS-Studio warning
Fixes #4402
|
|
PVS-Studio warning
Fixes #4402
|
|
PVS-Studio warning
Fixes #4402
|
|
Otherwise curl may be told to use for instance pop3 to
communicate with the doh server, which most likely
is not what you want.
Found through fuzzing.
Closes #4406
|
|
Closes #4406
|
|
Closes #4401
Fixes #4400
|
|
Curl_timeleft returns `timediff_t`, which is 64 bits wide also on
32-bit systems since commit b1616dad8f0.
Closes https://github.com/curl/curl/pull/4398
|
|
It was already fixed for BoringSSL in commit a0f8fccb1e0.
LibreSSL has had the second argument to SSL_CTX_set_min_proto_version
as uint16_t ever since the function was added in [0].
[0] https://github.com/libressl-portable/openbsd/commit/56f107201baefb5533486d665a58d8f57fd3aeda
Closes https://github.com/curl/curl/pull/4397
|
|
Prior to this change when a server returned a socks5 connect error then
curl would parse the destination address:port from that data and show it
to the user as the destination:
curld -v --socks5 10.0.3.1:1080 http://google.com:99
* SOCKS5 communication to google.com:99
* SOCKS5 connect to IPv4 172.217.12.206 (locally resolved)
* Can't complete SOCKS5 connection to 253.127.0.0:26673. (1)
curl: (7) Can't complete SOCKS5 connection to 253.127.0.0:26673. (1)
That's incorrect because the address:port included in the connect error
is actually a bind address:port (typically unused) and not the
destination address:port. This fix changes curl to show the destination
information that curl sent to the server instead:
curld -v --socks5 10.0.3.1:1080 http://google.com:99
* SOCKS5 communication to google.com:99
* SOCKS5 connect to IPv4 172.217.7.14:99 (locally resolved)
* Can't complete SOCKS5 connection to 172.217.7.14:99. (1)
curl: (7) Can't complete SOCKS5 connection to 172.217.7.14:99. (1)
curld -v --socks5-hostname 10.0.3.1:1080 http://google.com:99
* SOCKS5 communication to google.com:99
* SOCKS5 connect to google.com:99 (remotely resolved)
* Can't complete SOCKS5 connection to google.com:99. (1)
curl: (7) Can't complete SOCKS5 connection to google.com:99. (1)
Ref: https://tools.ietf.org/html/rfc1928#section-6
Closes https://github.com/curl/curl/pull/4394
|
|
Closes #4395
|
|
Follow-up from 03ebe66d70
|
|
Closes #4387
Fixes #4379
|