In providercheck(), when failing to open the "store", the exit path
would not previously free the created UI_METHOD and instead leak this
resource.
Pointed out by ZeroPath
Closes#19114
- tool_formparse: replace truncated `fseek` with `curlx_fseek`.
- tool_operate: replace truncated `fseek` with `curlx_fseek`.
- tool_paramhlp: replace local duplicate `myfseek`, with `curlx_fseek`.
Follow-up to 4fb12f2891#19100Closes#19107
Before this patch system `malloc()`/`free()` were used to allocate
the buffer returned in the `output_token` object from the debug stub
of `gss_init_sec_context()` when enabled via `CURL_STUB_GSS_CREDS` in
debug-enabled libcurl builds. This object is later released via stock
`gss_release_buffer()`, which, in the Windows builds of MIT Kerberos,
doesn't use the system `free()`, but the Win32 `HeapFree()`.
Fix it by using the GSS alloc/free macros: `gssalloc_malloc()` and
`gssalloc_free()` from `gssapi_alloc.h`.
To make this work without MIT Kerberos feature detection, use a canary
macro to detect a version which installs `gssapi_alloc.h` for Windows.
For <1.15 (2016-11-30) releases, that do not install it, disable the GSS
debug stub in libcurl.
Strictly speaking, non-Windows builds would also need to use GSS
allocators, but, detecting support for `gssapi_alloc.h` is impossible
without build-level logic. Built-level logic is complex and overkill,
and MIT Kerberos, as of 1.22.1, uses standard malloc/free on
non-Windows platforms anyway. (except in GSS debug builds.)
Follow-up to 73840836a5#17752Closes#19064
For files with sizes using an exact multiple of 256 bytes, the final
successful read(s) filled the buffer(s) and the subsequent fread
returned 0 for EOF, which caused read_file_into to fail.
Now, it needs to return 0 and not be EOF to be an error.
Follow-up to dd95a49d49
Pointed out by ZeroPath
Closes#19104
Avoid the possible 64-bit offset truncation when used on systems with
small 'long', like Windows.
bonus: make mime_open_file() return bool
Pointed out by ZeroPath
Closes#19100
The choice to continue processing incoming data although the
writeout of the headers/data failed is not obvious. Add a comment
explaining why this is done.
Closes#19093
The transfer loop used to check the socket and if no poll events
were seen, triggered a "DATA_IDLE" event into the filters to let
them schedule times/do things anyway.
Since we no longer check the socket, the filters have been called
already and the DATA_IDLE event is unnecessary work. Remove it.
Closes#19060
RFC 3617 defines two specific modes, "netascii" and "octet". This code
now checks only for those trailing ones - and not in the hostname since
they can't be there anymore.
Assisted-by: Jay Satiro
Closes#19070
Since it needs to be a trailing piece of the path avoiding strstr() is
faster and more reliable.
Also stopped checking the host name since it cannot actually be there
since quite a long while back. The URL parser doesn't allow such a
hostname.
Moved the check into its own subfunction too.
Closes#19069
In pop3_perform(), pop3->transfer was derived from the old
data->req.no_body. Then, pop3_perform_command() re-computed
data->req.no_body.
Now we instead call pop3_perform_command() first.
Reported-by: Joshua Rogers
Closes#19039
If there is lingering letters left on the right side after the paths
have been parsed, they are syntactically incorrect so returning error is
the safe thing to do.
Reported-by: Harry Sintonen
Closes#19030
Protocol handlers not flagging PROTOPT_SSL that allow reuse of existing
SSL connections now need to carry the flag PROTOPT_SSL_REUSE.
Add PROTOPT_SSL_REUSE to imap, ldap, pop3, smtp and ftp.
Add tests the http: urls do not reuse https: connections and vice versa.
Reported-by: Sakthi SK
Fixes#19006Closes#19007
Although the protocol should only run on index 0, there was a mix of
looked up sockindex and using constant 0 in tls send/recv.
Reported-by: Joshua Rogers
Closes#19004
Both the c-ares documentation and the c-ares source code contradict the
previous comment (and mentions/contains no such restriction).
Ref: #19001Closes#19014
