Age | Commit message (Collapse) | Author |
|
|
|
The internal defaults are important info
|
|
|
|
Clarify that the '-', '.', '_' or '~' letters are also not escaped since
they shouldn't according to RFC3986 section 2.3.
This is how this function has behaved since sep 2010, commit
5df13c31735fa0.
|
|
As the code already checks for it we can just as well make it official!
|
|
When set to a HTTP 1.0 proxy, that only affects the CONNECT request and
not the regular HTTP request.
|
|
The new libcurl and command line options are now described.
|
|
Added CURLOPT_TRANSFER_ENCODING as the option to set to request Transfer
Encoding in HTTP requests (if built zlib enabled). I also renamed
CURLOPT_ENCODING to CURLOPT_ACCEPT_ENCODING (while keeping the old name
around) to reduce the confusion when we have to encoding options for
HTTP.
--tr-encoding is now the new command line option for curl to request
this, and thus I updated the test cases accordingly.
|
|
Reported by: Hongli Lai
|
|
Stop the abuse of CURLE_FAILED_INIT as return code for things not being
init related by introducing two new return codes:
CURLE_NOT_BUILT_IN and CURLE_UNKNOWN_OPTION
CURLE_NOT_BUILT_IN replaces return code 4 that has been obsoleted for
several years. It is used for returning error when something is
attempted to be used but the feature/option was not enabled or
explictitly disabled at build-time. Getting this error mostly means that
libcurl needs to be rebuilt.
CURLE_FAILED_INIT is now saved and used strictly for init
failures. Getting this problem means something went seriously wrong,
like a resource shortage or similar.
CURLE_UNKNOWN_OPTION is the option formerly known as
CURLE_UNKNOWN_TELNET_OPTION (and the old name is still present,
separately defined to be removed in a very distant future). This error
code is meant to be used to return when an option is given to libcurl
that isn't known. This problem would mostly indicate a problem in the
program that uses libcurl.
|
|
The read callback must return the exact requested amount of data when it
is used for doing TFTP uploads. This is due to how it deals with data
internally. This could/should be fixed but for now we document the
existing behavior.
Reported by: Colin Blair
Bug: http://curl.haxx.se/mail/lib-2011-03/0319.html
|
|
If a new enough OpenSSL version is used, configure detects the TLS-SRP
support and enables it.
|
|
|
|
This avoids warnings generated by autoconf 2.68.
Signed-off-by: Dave Reisner <d@falconindy.com>
|
|
Scanned with a tool that checked for mistakes and this is the subsequent
cleanup.
|
|
|
|
CURLE_CHUNK_FAILED and CURLE_FTP_BAD_FILE_LIST were introduced in
7.21.0, not 7.20.1
|
|
When NSS-powered libcurl connected to a SSL server with
CURLOPT_SSL_VERIFYPEER equal to zero, NSS remembered that the peer
certificate was accepted by libcurl and did not ask the second time when
connecting to the same server with CURLOPT_SSL_VERIFYPEER equal to one.
This patch turns off the SSL session cache for the particular SSL socket
if peer verification is disabled. In order to avoid any performance
impact, the peer verification is completely skipped in that case, which
makes it even faster than before.
Bug: https://bugzilla.redhat.com/678580
|
|
|
|
Extend the docs to clarify that CURLOPT_SSH_KEYFUNCTION is only called
if the known hosts option is also correctly set!
|
|
CURLOPT_HTTPAUTH was mentioning CURLOPT_USERPASSWORD instead of
CURLOPT_PASSWORD.
Reported by: Mike Henshaw
|
|
I forgot to sort it when I added the CURL_SOCKOPT_* symbols
|
|
|
|
On second thought, I think CURLE_TLSAUTH_FAILED should be eliminated. It
was only being raised when an internal error occurred while allocating
or setting the GnuTLS SRP client credentials struct. For TLS
authentication failures, the general CURLE_SSL_CONNECT_ERROR seems
appropriate; its error string already includes "passwords" as a possible
cause. Having a separate TLS auth error code might also cause people to
think that a TLS auth failure means the wrong username or password was
entered, when it could also be a sign of a man-in-the-middle attack.
|
|
|
|
|
|
|
|
|
|
The default value is 1.
curl _uses_ a default CA bundle, it doesn't install one.
Drop the references to 7.10 as that is now >8 years old!
|
|
Extended the descriptions somewhat and made the options get listed next
to each other.
|
|
... and update the curl.1 and curl_easy_setopt.3 man pages such that
they do not suggest to use an OpenSSL utility if curl is not built
against OpenSSL.
Bug: https://bugzilla.redhat.com/669702
|
|
Bug: https://bugzilla.redhat.com/623663
|
|
|
|
|
|
It was added in 7.17.0 and is not deprecated
|
|
This is a meta symbol. OR this value together with a single specific
auth value to force libcurl to probe for un-restricted auth and if not,
only that single auth algorithm is acceptable.
For example you can use CURLAUTH_DIGEST|CURLAUTH_ONLY to make libcurl
first probe for what method to use, but yet only consider Digest to be
acceptable.
Using _only_ CURLAUTH_DIGEST without the CURLAUTH_ONLY field, will make
libcurl explicitly use Digest right away and not do any probing.
|
|
I also documented the filtering logic in the symbol-scan.pl function to
clarify why not all CURL_* symbols are included.
|
|
|
|
|
|
|
|
I've developed a script I call symbol-scan.pl that scans the curl.h and
multi.h header files and compare the symbols it finds in there with the
symbols symbols-in-versions documents and outputs a report on the
differences. Using this I've dug through the history to fill up
symbols-in-versions with all the symbols my script found mismatches for.
I will commit symbol-scan.pl separatly and think of a way to put it to
use in the build/tests so that we from now on will get this in-sync
check automatically.
|
|
|
|
|
|
|
|
It is for FTP, SMTP, POP3, IMAP at least.
|
|
The option takes a parameter that should be 1 or 0 to enable or disable
the feature.
URL: http://curl.haxx.se/bug/view.cgi?id=3086428
|
|
|
|
The invocation of autoconf's AC_PATH_PROG( ) is not quite right for
finding curl-config. This fix corrects the negative case (where
curl-config is not found).
|
|
The macro provides a --with-libcurl option that expects a PREFIX to be
specified and not actually a "directory" in which libcurl will be found.
This now spells that out more clearly.
Reported by: Dan Locks
Bug: http://curl.haxx.se/bug/view.cgi?id=3079891
|
|
Make it explicit that setting CURLOPT_DIRLISTONLY to 1 will make libcurl
to list the directory.
|