mirror of
https://github.com/curl/curl.git
synced 2025-02-17 14:59:45 +08:00
KNOWN_BUGS: remove items not considered bugs any more
- CURL_GLOBAL_SSL This option was changed in libcurl 7.57.0 and clearly it has not caused too many issues and a lot of time has passed. - Store TLS context per transfer instead of per connection This is a possible future optimization. One that is much less important and interesting since the added support for CA caching. - Microsoft telnet server This bug was filed in May 2007 against curl 7.16.1 and we have not received further reports. - active FTP over a SOCKS Actually, proxies in general is not working with active FTP mode. This is now added in proxy documentation. - DICT responses show the underlying protocol curl still does this, but since this is now an established behavior since forever we cannot change it easily and adding an option for it seems crazy as this protocol is not so little its not worth it. Let's just live with it. - Secure Transport disabling hostname validation also disables SNI This is an already documented restriction in Secure Transport. - CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM The curl_formadd() function is marked and documented as deprecated. No point in collecting bugs for it. It should not be used further. - STARTTRANSFER time is wrong for HTTP POSTs After close source code inspection I cannot see how this is true or that there is any special treatment for different HTTP methods. We also have not received many further reports on this, making me strongly suspect that this is no (longer an) issue. - multipart formposts file name encoding The once proposed RFC 5987-encoding is since RFC 7578 documented as MUST NOT be used. The since then implemented MIME API allows the user to set the name on their own and can thus provide it encoded as it wants. - DoH is not used for all name resolves when enabled It is questionable if users actually want to use DoH for interface and FTP port name resolving. This restriction is now documented and we advice users against using name resolving at all for these functions. Closes #10043
This commit is contained in:
Daniel Stenberg
parent
da8e215f6c
commit
f0b374f662
126
docs/KNOWN_BUGS
126
docs/KNOWN_BUGS
@ -12,25 +12,18 @@ check the changelog of the current development status, as one or more of these
|
||||
problems may have been fixed or changed somewhat since this was written.
|
||||
|
||||
1. HTTP
|
||||
1.3 STARTTRANSFER time is wrong for HTTP POSTs
|
||||
1.4 multipart formposts file name encoding
|
||||
1.5 Expect-100 meets 417
|
||||
1.8 DoH is not used for all name resolves when enabled
|
||||
1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
|
||||
|
||||
2. TLS
|
||||
2.3 Unable to use PKCS12 certificate with Secure Transport
|
||||
2.4 Secure Transport will not import PKCS#12 client certificates without a password
|
||||
2.5 Client cert handling with Issuer DN differs between backends
|
||||
2.6 CURL_GLOBAL_SSL
|
||||
2.7 Client cert (MTLS) issues with Schannel
|
||||
2.8 Schannel disable CURLOPT_SSL_VERIFYPEER and verify hostname
|
||||
2.9 TLS session cache does not work with TFO
|
||||
2.10 Store TLS context per transfer instead of per connection
|
||||
2.11 Schannel TLS 1.2 handshake bug in old Windows versions
|
||||
2.12 FTPS with Schannel times out file list operation
|
||||
2.13 CURLOPT_CERTINFO results in CURLE_OUT_OF_MEMORY with Schannel
|
||||
2.14 Secure Transport disabling hostname validation also disables SNI
|
||||
2.15 Renegotiate from server may cause hang for OpenSSL backend
|
||||
|
||||
3. Email protocols
|
||||
@ -81,9 +74,6 @@ problems may have been fixed or changed somewhat since this was written.
|
||||
7.11 FTPS upload data loss with TLS 1.3
|
||||
7.12 FTPS directory listing hangs on Windows with Schannel
|
||||
|
||||
8. TELNET
|
||||
8.2 Microsoft telnet server
|
||||
|
||||
9. SFTP and SCP
|
||||
9.1 SFTP does not do CURLOPT_POSTQUOTE correct
|
||||
9.2 wolfssh: publickey auth does not work
|
||||
@ -92,7 +82,6 @@ problems may have been fixed or changed somewhat since this was written.
|
||||
|
||||
10. SOCKS
|
||||
10.3 FTPS over SOCKS
|
||||
10.4 active FTP over a SOCKS
|
||||
|
||||
11. Internals
|
||||
11.1 Curl leaks .onion hostnames in DNS
|
||||
@ -116,9 +105,6 @@ problems may have been fixed or changed somewhat since this was written.
|
||||
13. TCP/IP
|
||||
13.2 Trying local ports fails on Windows
|
||||
|
||||
14. DICT
|
||||
14.1 DICT responses show the underlying protocol
|
||||
|
||||
15. CMake
|
||||
15.1 use correct SONAME
|
||||
15.2 support build with GnuTLS
|
||||
@ -153,24 +139,6 @@ problems may have been fixed or changed somewhat since this was written.
|
||||
|
||||
1. HTTP
|
||||
|
||||
1.3 STARTTRANSFER time is wrong for HTTP POSTs
|
||||
|
||||
Wrong STARTTRANSFER timer accounting for POST requests Timer works fine with
|
||||
GET requests, but while using POST the time for CURLINFO_STARTTRANSFER_TIME
|
||||
is wrong. While using POST CURLINFO_STARTTRANSFER_TIME minus
|
||||
CURLINFO_PRETRANSFER_TIME is near to zero every time.
|
||||
|
||||
https://github.com/curl/curl/issues/218
|
||||
https://curl.se/bug/view.cgi?id=1213
|
||||
|
||||
1.4 multipart formposts file name encoding
|
||||
|
||||
When creating multipart formposts. The file name part can be encoded with
|
||||
something beyond ascii but currently libcurl will only pass in the verbatim
|
||||
string the app provides. There are several browsers that already do this
|
||||
encoding. The key seems to be the updated draft to RFC2231:
|
||||
https://datatracker.ietf.org/doc/html/draft-reschke-rfc2231-in-http-02
|
||||
|
||||
1.5 Expect-100 meets 417
|
||||
|
||||
If an upload using Expect: 100-continue receives an HTTP 417 response, it
|
||||
@ -178,27 +146,6 @@ problems may have been fixed or changed somewhat since this was written.
|
||||
the client application to redo the transfer after disabling Expect:.
|
||||
https://curl.se/mail/archive-2008-02/0043.html
|
||||
|
||||
1.8 DoH is not used for all name resolves when enabled
|
||||
|
||||
Even if DoH is specified to be used, there are some name resolves that are
|
||||
done without it. This should be fixed. When the internal function
|
||||
`Curl_resolver_wait_resolv()` is called, it does not use DoH to complete the
|
||||
resolve as it otherwise should.
|
||||
|
||||
See https://github.com/curl/curl/pull/3857 and
|
||||
https://github.com/curl/curl/pull/3850
|
||||
|
||||
1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
|
||||
|
||||
When using libcurl to POST form data using a FILE* with the CURLFORM_STREAM
|
||||
option of curl_formadd(). I notice that if the connection drops at just the
|
||||
right time, the POST is reattempted without the data from the file. It seems
|
||||
like the file stream position is not getting reset to the beginning of the
|
||||
file. I found the CURLOPT_SEEKFUNCTION option and set that with a function
|
||||
that performs an fseek() on the FILE*. However, setting that did not seem to
|
||||
fix the issue or even get called. See https://github.com/curl/curl/issues/768
|
||||
|
||||
|
||||
2. TLS
|
||||
|
||||
2.3 Unable to use PKCS12 certificate with Secure Transport
|
||||
@ -219,34 +166,6 @@ problems may have been fixed or changed somewhat since this was written.
|
||||
|
||||
See https://github.com/curl/curl/issues/1411
|
||||
|
||||
2.6 CURL_GLOBAL_SSL
|
||||
|
||||
Since libcurl 7.57.0, the flag CURL_GLOBAL_SSL is a no-op. The change was
|
||||
merged in https://github.com/curl/curl/commit/d661b0afb571a
|
||||
|
||||
It was removed since it was
|
||||
|
||||
A) never clear for applications on how to deal with init in the light of
|
||||
different SSL backends (the option was added back in the days when life
|
||||
was simpler)
|
||||
|
||||
B) multissl introduced dynamic switching between SSL backends which
|
||||
emphasized (A) even more
|
||||
|
||||
C) libcurl uses some TLS backend functionality even for non-TLS functions (to
|
||||
get "good" random) so applications trying to avoid the init for
|
||||
performance reasons would do wrong anyway
|
||||
|
||||
D) not documented carefully so all this mostly just happened to work
|
||||
for some users
|
||||
|
||||
However, in spite of the problems with the feature, there were some users who
|
||||
apparently depended on this feature and who now claim libcurl is broken for
|
||||
them. The fix for this situation is not obvious as a downright revert of the
|
||||
patch is totally ruled out due to those reasons above.
|
||||
|
||||
https://github.com/curl/curl/issues/2276
|
||||
|
||||
2.7 Client cert (MTLS) issues with Schannel
|
||||
|
||||
See https://github.com/curl/curl/issues/3145
|
||||
@ -261,16 +180,6 @@ problems may have been fixed or changed somewhat since this was written.
|
||||
|
||||
See https://github.com/curl/curl/issues/4301
|
||||
|
||||
2.10 Store TLS context per transfer instead of per connection
|
||||
|
||||
The GnuTLS `backend->cred` and the OpenSSL `backend->ctx` data and their
|
||||
proxy versions (and possibly other TLS backends), could be better moved to be
|
||||
stored in the Curl_easy handle instead of in per connection so that a single
|
||||
transfer that makes multiple connections can reuse the context and reduce
|
||||
memory consumption.
|
||||
|
||||
https://github.com/curl/curl/issues/5102
|
||||
|
||||
2.11 Schannel TLS 1.2 handshake bug in old Windows versions
|
||||
|
||||
In old versions of Windows such as 7 and 8.1 the Schannel TLS 1.2 handshake
|
||||
@ -289,20 +198,6 @@ problems may have been fixed or changed somewhat since this was written.
|
||||
|
||||
https://github.com/curl/curl/issues/8741
|
||||
|
||||
2.14 Secure Transport disabling hostname validation also disables SNI
|
||||
|
||||
SNI is the hostname that is sent by the TLS library to the server as part of
|
||||
the TLS handshake. Secure Transport does not send SNI when hostname validation
|
||||
is disabled. Servers that host multiple websites may not know which
|
||||
certificate to serve without SNI or which backend server to connect to. The
|
||||
server may serve the certificate of a default server or abort.
|
||||
|
||||
If a server aborts a handshake then curl shows error "SSL peer handshake
|
||||
failed, the server most likely requires a client certificate to connect".
|
||||
In this case the error may also have been caused by lack of SNI.
|
||||
|
||||
https://github.com/curl/curl/issues/6347
|
||||
|
||||
2.15 Renegotiate from server may cause hang for OpenSSL backend
|
||||
|
||||
A race condition has been observed when, immediately after the initial
|
||||
@ -634,14 +529,6 @@ problems may have been fixed or changed somewhat since this was written.
|
||||
|
||||
https://github.com/curl/curl/issues/9161
|
||||
|
||||
8. TELNET
|
||||
|
||||
8.2 Microsoft telnet server
|
||||
|
||||
There seems to be a problem when connecting to the Microsoft telnet server.
|
||||
https://curl.se/bug/view.cgi?id=649
|
||||
|
||||
|
||||
9. SFTP and SCP
|
||||
|
||||
9.1 SFTP does not do CURLOPT_POSTQUOTE correct
|
||||
@ -683,10 +570,6 @@ problems may have been fixed or changed somewhat since this was written.
|
||||
|
||||
libcurl does not support FTPS over a SOCKS proxy.
|
||||
|
||||
10.4 active FTP over a SOCKS
|
||||
|
||||
libcurl does not support active FTP over a SOCKS proxy
|
||||
|
||||
|
||||
11. Internals
|
||||
|
||||
@ -826,15 +709,6 @@ problems may have been fixed or changed somewhat since this was written.
|
||||
|
||||
https://github.com/curl/curl/issues/8112
|
||||
|
||||
14. DICT
|
||||
|
||||
14.1 DICT responses show the underlying protocol
|
||||
|
||||
When getting a DICT response, the protocol parts of DICT are not stripped off
|
||||
from the output.
|
||||
|
||||
https://github.com/curl/curl/issues/1809
|
||||
|
||||
15. CMake
|
||||
|
||||
15.1 use correct SONAME
|
||||
|
||||
@ -45,3 +45,6 @@ or pass in a colon with %3a.
|
||||
The proxy host can be specified the same way as the proxy environment
|
||||
variables, including the protocol prefix (http://) and the embedded user +
|
||||
password.
|
||||
|
||||
When a proxy is used, the active FTP mode as set with --ftp-port, cannot be
|
||||
used.
|
||||
|
||||
@ -43,12 +43,12 @@ system's default IP address. Default FTP operations are passive, and thus
|
||||
will not use PORT.
|
||||
|
||||
The address can be followed by a ':' to specify a port, optionally followed by
|
||||
a '-' to specify a port range. If the port specified is 0, the operating
|
||||
system will pick a free port. If a range is provided and all ports in the
|
||||
a '-' to specify a port range. If the port specified is 0, the operating
|
||||
system will pick a free port. If a range is provided and all ports in the
|
||||
range are not available, libcurl will report CURLE_FTP_PORT_FAILED for the
|
||||
handle. Invalid port/range settings are ignored. IPv6 addresses followed by
|
||||
a port or port range have to be in brackets. IPv6 addresses without
|
||||
port/range specifier can be in brackets.
|
||||
handle. Invalid port/range settings are ignored. IPv6 addresses followed by a
|
||||
port or port range have to be in brackets. IPv6 addresses without port/range
|
||||
specifier can be in brackets.
|
||||
|
||||
Examples with specified ports:
|
||||
|
||||
@ -59,6 +59,11 @@ Examples with specified ports:
|
||||
[::1]:1234-4567
|
||||
.fi
|
||||
|
||||
We strongly advise against specifying the address with a name, as it causes
|
||||
libcurl to do a blocking name resolve call to retrieve the IP address. That
|
||||
name resolve operation will \fBnot\fP use DNS-over-HTTPS even if
|
||||
\fICURLOPT_DOH_URL(3)\fP is set.
|
||||
|
||||
You disable PORT again and go back to using the passive version by setting
|
||||
this option to NULL.
|
||||
|
||||
|
||||
@ -38,16 +38,21 @@ or a host name.
|
||||
|
||||
If the parameter starts with "if!" then it is treated as only as interface
|
||||
name and no attempt will ever be named to do treat it as an IP address or to
|
||||
do name resolution on it. If the parameter starts with \&"host!" it is
|
||||
treated as either an IP address or a hostname. Hostnames are resolved
|
||||
synchronously. Using the if! format is highly recommended when using the
|
||||
multi interfaces to avoid allowing the code to block. If "if!" is specified
|
||||
but the parameter does not match an existing interface, CURLE_INTERFACE_FAILED
|
||||
is returned from the libcurl function used to perform the transfer.
|
||||
do name resolution on it. If the parameter starts with \&"host!" it is treated
|
||||
as either an IP address or a hostname.
|
||||
|
||||
If "if!" is specified but the parameter does not match an existing interface,
|
||||
\fICURLE_INTERFACE_FAILED\fP is returned from the libcurl function used to
|
||||
perform the transfer.
|
||||
|
||||
libcurl does not support using network interface names for this option on
|
||||
Windows.
|
||||
|
||||
We strongly advise against specifying the interface with a hostname, as it
|
||||
causes libcurl to do a blocking name resolve call to retrieve the IP
|
||||
address. That name resolve operation will \fBnot\fP use DNS-over-HTTPS even if
|
||||
\fICURLOPT_DOH_URL(3)\fP is set.
|
||||
|
||||
The application does not have to keep the string around after setting this
|
||||
option.
|
||||
.SH DEFAULT
|
||||
|
||||
@ -80,6 +80,9 @@ localhost for the host part. e.g. socks5h://localhost/path/to/socket.sock
|
||||
|
||||
The application does not have to keep the string around after setting this
|
||||
option.
|
||||
|
||||
When a proxy is used, the active FTP mode as set with \fICUROPT_FTPPORT(3)\fP,
|
||||
cannot be used.
|
||||
.SH "Environment variables"
|
||||
libcurl respects the proxy environment variables named \fBhttp_proxy\fP,
|
||||
\fBftp_proxy\fP, \fBsftp_proxy\fP etc. If set, libcurl will use the specified
|
||||
|
||||
Loading…
Reference in New Issue
Block a user