4.9 Curl can't authenticate to the server that requires NTLM?
- NTLM support requires OpenSSL, GnuTLS, NSS, Secure Transport, or Microsoft
- Windows libraries at build-time to provide this functionality.
+ NTLM support requires OpenSSL, GnuTLS, mbedTLS, NSS, Secure Transport, or
+ Microsoft Windows libraries at build-time to provide this functionality.
NTLM is a Microsoft proprietary protocol. Proprietary formats are evil. You
should not use such ones.
your system has such. Note that you must never share the same handle in
multiple threads.
- libcurl's implementation of timeouts might use signals (depending on what it
- was built to use for name resolving), and signal handling is generally not
- thread-safe. Multi-threaded Applicationss that call libcurl from different
- threads (on different handles) might want to use CURLOPT_NOSIGNAL, e.g.:
-
- curl_easy_setopt(handle, CURLOPT_NOSIGNAL, true);
-
- If you use a OpenSSL-powered libcurl in a multi-threaded environment, you
- need to provide one or two locking functions:
-
- https://www.openssl.org/docs/crypto/threads.html
-
- If you use a GnuTLS-powered libcurl in a multi-threaded environment, you
- need to provide locking function(s) for libgcrypt (which is used by GnuTLS
- for the crypto functions).
-
- https://web.archive.org/web/20111103083330/http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applications.html
-
- No special locking is needed with a NSS-powered libcurl. NSS is thread-safe.
+ There may be some exceptions to thread safety depending on how libcurl was
+ built. Please review the guidelines for thread safety to learn more:
+ https://curl.haxx.se/libcurl/c/threadsafe.html
5.2 How can I receive all data into a large memory chunk?
CURLOPT_CUSTOMREQUEST to alter what exact listing command libcurl would use
to list the files.
- The follow-up question that tend to follow the previous one, is how a
- program is supposed to parse the directory listing. How does it know what's
- a file and what's a dir and what's a symlink etc. The harsh reality is that
- FTP provides no such fine and easy-to-parse output. The output format FTP
- servers respond to LIST commands are entirely at the server's own liking and
- the NLST output doesn't reveal any types and in many cases don't even
- include all the directory entries. Also, both LIST and NLST tend to hide
- unix-style hidden files (those that start with a dot) by default so you need
- to do "LIST -a" or similar to see them.
-
- The application thus needs to parse the LIST output. One such existing
+ The follow-up question tends to be how is a program supposed to parse the
+ directory listing. How does it know what's a file and what's a dir and what's
+ a symlink etc. If the FTP server supports the MLSD command then it will
+ return data in a machine-readable format that can be parsed for type. The
+ types are specified by RFC3659 section 7.5.1. If MLSD is not supported then
+ you have to work with what you're given. The LIST output format is entirely
+ at the server's own liking and the NLST output doesn't reveal any types and
+ in many cases doesn't even include all the directory entries. Also, both LIST
+ and NLST tend to hide unix-style hidden files (those that start with a dot)
+ by default so you need to do "LIST -a" or similar to see them.
+
+ Example - List only directories.
+ ftp.funet.fi supports MLSD and ftp.kernel.org does not:
+
+ curl -s ftp.funet.fi/pub/ -X MLSD | \
+ perl -lne 'print if s/(?:^|;)type=dir;[^ ]+ (.+)$/$1/'
+
+ curl -s ftp.kernel.org/pub/linux/kernel/ | \
+ perl -lne 'print if s/^d[-rwx]{9}(?: +[^ ]+){7} (.+)$/$1/'
+
+ If you need to parse LIST output in libcurl one such existing
list parser is available at https://cr.yp.to/ftpparse.html Versions of
libcurl since 7.21.0 also provide the ability to specify a wildcard to
download multiple files from one FTP directory.
projects / platform / upstream / curl.git / blobdiff