- bufref: use strndup
- cookie: use strndup
- formdata: use strndup
- ftp: use strndup
- gtls: use aprintf instead of malloc + strcpy * 2
- http: use strndup
- mbedtls: use strndup
- md4: use memdup
- ntlm: use memdup
- ntlm_sspi: use strndup
- pingpong: use memdup
- rtsp: use strndup instead of malloc, memcpy and null-terminate
- sectransp: use strndup
- socks_gssapi.c: use memdup
- vtls: use dynbuf instead of malloc, snprintf and memcpy
- vtls: use strdup instead of malloc + memcpy
- wolfssh: use strndup
Closes#12453
To help users better understand where the URL (and denied scheme) comes
from. Also removed "in libcurl" from the message, since the disabling
can be done by the application.
The error message now says "not supported" or "disabled" depending on
why it was denied:
Protocol "hej" not supported
Protocol "http" disabled
And in redirects:
Protocol "hej" not supported (in redirect)
Protocol "http" disabled (in redirect)
Reported-by: Mauricio Scheffer
Fixes#12465Closes#12469
- expecially in is_alive checks on connections, we might
see incoming packets on streams already forgotten and closed,
leading to errors reported by nghttp3. Ignore those.
Closes#12449
The foo_st names don't appear in OpenSSL public API documentation. The
FOO typedefs are more common. This header was already referencing
SSL_CTX via <openssl/ssl.h>. There is a comment about avoiding
<openssl/x509v3.h>, but OpenSSL actually declares all the typedefs in
<openssl/ossl_typ.h>, which is already included by <openssl/ssl.h> (and
every other OpenSSL header), so just use that. Though I've included it
just to be explicit.
(I'm also fairly sure including <openssl/ssl.h> already triggers the
Schannel conflicts anyway. The comment was probably just out of date.)
Closes#12439
- fix cases where ngtcp2 invokes callbacks on streams that
nghttp3 has already forgotten. Ignore the NGHTTP3_ERR_STREAM_NOT_FOUND
in these cases as it is normal behaviour.
Closes#12435
char variables if unspecified can be either signed or unsigned depending
on the platform according to the C standard; in most platforms, they are
signed.
This meant that the *i<32 waas always true for bytes with the top bit
set. So they were always getting encoded as \uXXXX, and then since they
were also signed negative, they were getting extended with 1s causing
'\xe2' to be expanded to \uffffffe2, for example:
$ curl --variable 'v=“' --expand-write-out '{{v:json}}\n' file:///dev/null
\uffffffe2\uffffff80\uffffff9c
I fixed this bug by making the code use explicitly unsigned char*
variables instead of char* variables.
Test 268 verifies
Reported-by: iconoclasthero
Closes#12434
... as there is nothing to wait for then, it just waits. Otherwise, this
causes much more CPU work and updates than necessary during ratelimit
periods.
Ref: https://curl.se/mail/lib-2023-11/0056.htmlCloses#12430
This handles cases of some bi-directional "upgrade" scenarios
(i.e. WebSockets) where sending is paused until some "upgrade" handshake
is completed, but server rejects the handshake and closes the
connection.
Closes#12428
The script errorcodes.pl extracts all error codes from all headers and
checks that they are all documented, then checks that all documented
error codes are also specified in a header file.
Closes#12424
When the progress bar was made max width (256 columns), the fly()
function attempted to generate its output buffer too long so that the
trailing carriage return would not fit and then the output would show
wrongly. The fly function is called when the expected total transfer is
unknown, which could be one or more progress calls before the actual
progress meter get shown when the expected transfer size is provided.
This new take also replaces the msnprintf() call with a much simpler
memset() for speed.
Reported-by: Tim Hill
Fixes#12407Closes#12415
When the config file parser detects a word that *probably* should be
quoted, mention double-quotes as a possible remedy.
Test 459 verifies.
Proposed-by: Jiehong on github
Fixes#12409Closes#12412
