cookies: Improve errorhandling for reading cookiefile
The existing programming had some issues with errorhandling for reading
the cookie file. If the file failed to open, we would silently ignore it
and continue as if there was no file (or stdin) passed. In this case, we
would also call fclose() on the NULL FILE pointer, which is undefined
behavior. Fix by ensuring that the FILE pointer is set before calling
fclose on it, and issue a warning in case the file cannot be opened.
Erroring out on nonexisting file would break backwards compatibility of
very old behavior so we can't really go there.
Closes: #8699 Reviewed-by: Daniel Stenberg <daniel@haxx.se> Reviewed-by: Jay Satiro <raysatiro@yahoo.com>
Gisle Vanem [Mon, 18 Apr 2022 06:45:14 +0000 (02:45 -0400)]
unit1620: call global_init before calling Curl_open
Curl_open calls the resolver init and on Windows if the resolver backend
is c-ares then the Windows sockets library (winsock) must already have
been initialized (via global init).
tool_paramhlp: use feof(3) to identify EOF correctly when using fread(3)
This loop was using the number of bytes read from the file as condition
to keep reading.
From Linux's fread(3) man page:
> On success, fread() and fwrite() return the number of items read or
> written. This number equals the number of bytes transferred only when
> size is 1. If an error occurs, or the end of the file is reached, the
> return value is a short item count (or zero).
>
> The file position indicator for the stream is advanced by the number
> of bytes successfully read or written.
>
> fread() does not distinguish between end-of-file and error, and
> callers must use feof(3) and ferror(3) to determine which occurred.
This means that nread!=0 doesn't make much sense as an end condition for
the loop: nread==0 doesn't necessarily mean that EOF has been reached or
an error has occured (but that is usually the case) and nread!=0 doesn't
necessarily mean that EOF has not been reached or that no read errors
have occured. feof(3) and ferror(3) should be uses when using fread(3).
Currently curl has to performs an extra fread(3) call to get a return
value equal to 0 to stop looping.
This usually "works" (even though nread==0 shouldn't be interpreted as
EOF) if stdin is a pipe because EOF usually marks the "real" end of the
stream, so the extra fread(3) call will return immediately and the extra
read syscall won't be noticeable:
But this doesn't work if curl is reading from stdin, stdin is a
terminal, and the EOF is being emulated using a shell with ^D. Two
consecutive ^D will be required in this case to actually make curl stop
reading:
bash-5.1$ curl -F file=@- 0x0.st
a
^D^D
http://0x0.st/oRs.txt
bash-5.1$
A possible workaround to this issue is to use a program that handles EOF
correctly to indirectly send data to curl's stdin:
This patch makes curl handle EOF properly when using fread(3) in
file2memory() so that the workaround is not necessary.
Since curl was previously ignoring read errors caused by this fread(3),
ferror(3) is also used in the condition of the loop: read errors and EOF
will have the same meaning; this is done to somewhat preserve the old
behaviour instead of making the command fail when a read error occurs.
Daniel Stenberg [Sun, 17 Apr 2022 09:21:15 +0000 (11:21 +0200)]
gen.pl: change wording for mutexed options
Instead of saying "This option overrides NNN", now say "This option is
mutually exclusive to NNN" in the generated man page ouput, as the
option does not in all cases actually override the others but they are
always mutually exclusive.
infof: consistent capitalization of warning messages
Ensure that all infof calls with a warning message are capitalized
in the same way. At some point we should probably set up a style-
guide for infof but until then let's aim for a little consistenncy
where we can.
Closes: #8711 Reviewed-by: Daniel Stenberg <daniel@haxx.se>
ngtcp2: fix HTTP/3 upload stall and avoid busy loop
This commit fixes HTTP/3 upload stall if upload data is larger than
H3_SEND_SIZE. Only check writability of socket if a stream is
writable to avoid busy loop when QUIC flow control window is filled
up, or upload buffer is full.
Daniel Stenberg [Fri, 1 Apr 2022 11:23:04 +0000 (13:23 +0200)]
http2: RST the stream if we stop it on our own will
For the "simulated 304" case the done-call isn't considered "premature"
but since the server didn't close the stream it needs to be reset to
stop delivering data.
Jay Satiro [Sun, 13 Feb 2022 21:58:04 +0000 (16:58 -0500)]
projects: Update VC version names for VS2017, VS2022
- Rename VC15 -> VC14.10, VC17 -> VC14.30.
The projects directory that holds the pre-generated Visual Studio
project files uses VC<ver> to indicate the MSVC version. At some point
support for Visual Studio 2017 (Visual Studio version 15 which uses MSVC
14.10) was added as VC15. Visual Studio 2022 (Visual Studio version 17
which uses MSVC 14.30) project files were recently added and followed
that same format using VC17.
There is no such MSVC version (yet) as VC15 or VC17.
For VS 2017 for example, the name we use is correct as either VS17,
VS2017, VC14.10. I opted for the latter since we use VC for earlier
versions (eg VC10, VC12, etc).
Marc Hoersken [Mon, 14 Mar 2022 23:16:46 +0000 (00:16 +0100)]
tests/server/util.h: align WIN32 condition with util.c
There is no need to test for both _WIN32 and WIN32 as curl_setup.h
automatically defines the later if the first one is defined.
Also tests/server/util.c is only checking for WIN32 arouund the
implementation of win32_perror, so just defining _WIN32
would not be sufficient for a successful compilation.
Reviewed-by: Daniel Stenberg Reviewed-by: Jay Satiro
Closes #8594
Jay Satiro [Thu, 17 Mar 2022 19:31:10 +0000 (15:31 -0400)]
gtls: fix build for disabled TLS-SRP
Prior to this change if, at build time, the GnuTLS backend was found to
have TLS-SRP support (HAVE_GNUTLS_SRP) but TLS-SRP was disabled in curl
via --disable-tls-srp (!USE_TLS_SRP) then a build error would occur.
Bug: https://curl.se/mail/lib-2022-03/0046.html Reported-by: Robert Brose
Closes https://github.com/curl/curl/pull/8604
Jay Satiro [Sat, 12 Mar 2022 23:23:12 +0000 (18:23 -0500)]
docs/opts: Mention Schannel client cert type is P12
Schannel backend code behaves same as Secure Transport, it expects a P12
certificate file or the name of a certificate already in the user's OS
key store. Also, both backends ignore CURLOPT_SSLKEY (tool: --key)
because they expect the private key to already be available from the
keystore or P12 certificate.
Daniel Stenberg [Tue, 22 Mar 2022 10:14:45 +0000 (11:14 +0100)]
test1135: sync with recent API updates
This test verifies that the order of functions in public headers remain
the same but hasn't been updated to care for recently added header
files. The order is important for some few platforms - or VERSIONINFO
needs to updated.
projects / thirdparty / curl.git / log
