| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Info: http://curl.haxx.se/mail/lib-2012-04/0170.html
|
|
This protects from attribute names being defined by third party's code.
Improvement: http://curl.haxx.se/mail/lib-2012-04/0127.html
|
|
Configuration files such as curl_config.h and all config-*.h no longer exist
nor are generated/copied into 'src' directory, now these only exist in 'lib'
directory from where curl tool sources uses them.
Additionally old src/setup.h has been refactored into src/tool_setup.h which
now pulls lib/setup.h
The possibility of a makefile needing an include path adjustment exists.
|
|
As it turns out, some people do want that after all.
|
|
|
|
Added a new CURLOPT_MAIL_AUTH option that allows the calling program to
set the optional AUTH parameter in the MAIL FROM command.
When this option is specified and an authentication mechanism is used
to communicate with the mail server then the AUTH parameter will be
included in the MAIL FROM command. This is particularly useful when the
calling program is acting as a relay in a trusted environment and
performing server to server communication, as it allows the relaying
server to specify the address of the mailbox that was used to
authenticate and send the original email.
|
|
I accidentally left the lowest bits 01 before
|
|
and updated the end year in the generic copyright string
|
|
Allow an appliction to set libcurl specific SSL options. The first and
only options supported right now is CURLSSLOPT_ALLOW_BEAST.
It will make libcurl to disable any work-arounds the underlying SSL
library may have to address a known security flaw in the SSL3 and TLS1.0
protocol versions.
This is a reaction to us unconditionally removing that behavior after
this security advisory:
http://curl.haxx.se/docs/adv_20120124B.html
... it did however cause a lot of programs to fail because of old
servers not liking this work-around. Now programs can opt to decrease
the security in order to interoperate with old servers better.
|
|
This adds three new options to control the behavior of TCP keepalives:
- CURLOPT_TCP_KEEPALIVE: enable/disable probes
- CURLOPT_TCP_KEEPIDLE: idle time before sending first probe
- CURLOPT_TCP_KEEPINTVL: delay between successive probes
While not all operating systems support the TCP_KEEPIDLE and
TCP_KEEPINTVL knobs, the library will still allow these options to be
set by clients, silently ignoring the values.
|
|
|
|
In commit c834213ad52 we re-used some obsolete error codes, and here are
two defines that makes sure existing source codes that happen to use any
of these deprecated ones will still compile.
As usual, define CURL_NO_OLDIES to avoid getting these "precaution
defines".
|
|
1- Two new error codes are introduced.
CURLE_FTP_ACCEPT_FAILED to be set whenever ACCEPTing fails because of
FTP server connected.
CURLE_FTP_ACCEPT_TIMEOUT to be set whenever ACCEPTing timeouts.
Neither of these errors are considered fatal and control connection
remains OK because it could just be a firewall blocking server to
connect to the client.
2- One new setopt option was introduced.
CURLOPT_ACCEPTTIMEOUT_MS
It sets the maximum amount of time FTP client is going to wait for a
server to connect. Internal default accept timeout is 60 seconds.
|
|
When working with the Android Standalone Toolchain the compiler defines
this macro:
/path/to/arm-linux-androideabi-gcc -E -dM - < /dev/null \
| grep -i android
#define __ANDROID__ 1
We really need to check both ANDROID and __ANDROID__ since I've observed
that:
* if you use Android.mk file(s) and the 'ndk-build' script (aka vanilla
way), ANDROID is predefined (see -DANDROID extra C flag),
* if you use the Android Standalone Toolchain, then __ANDROID__ is
predefined as stated by the compiler
|
|
|
|
|
|
There might be situations where a user would want to unset this option.
Avoid forcing him/her to cast the NULL argument to (char *) in order to
get past the compile time typecheck.
|
|
Don't even declare the struct members for disabled features
Introducing the CURLSHE_NOT_BUILT_IN return code for the share interface
when trying to set a sharing option that has been disabled (or not
enabled) in the library.
|
|
|
|
|
|
|
|
Allow (*curl_write_callback) write callbacks to return
CURL_WRITEFUNC_OUT_OF_MEMORY to properly indicate libcurl of OOM conditions
inside the callback itself.
|
|
|
|
Functions renamed:
Curl_output_ntlm_sso -> Curl_output_ntlm_wb
sso_ntlm_close -> wb_ntlm_close
sso_ntlm_response -> wb_ntlm_response
sso_ntlm_initiate -> wb_ntlm_initiate
Preprocessor symbols renamed:
CURLAUTH_NTLM_SSO -> CURLAUTH_NTLM_WB
CURL_VERSION_NTLM_SSO -> CURL_VERSION_NTLM_WB
|
|
This is to aid easier machine parsing and to make sure nobody who reads
these header lines can miss the info.
|
|
|
|
|
|
Allow compilation of libcurl and curl using BSD-style lwIP on Win32.
In order to compile libcurl and curl with this support it is necessary
to edit files lib/config-win32.h and src/config-win32.h and uncomment
a line to make definition of preprocessor symbol USE_LWIPSOCK visible.
Afterwards you can compile as usual.
In order to use compiled library with BSD-style lwIP TCP/IP stack in
your program it is mandatory that you include lwIP header file <lwip/opt.h>
before including <curl/curl.h> or <curl/multi.h>
Compilation has been verified with lwIP 1.4.0 and contrib-1.4.0 from:
http://download.savannah.gnu.org/releases/lwip/lwip-1.4.0.zip
http://download.savannah.gnu.org/releases/lwip/contrib-1.4.0.zip
Have fun!
|
|
|
|
Suggested by Richard Silverman.
|
|
Curl_gss_init_sec_context got new parameter - SessionHandle.
Signed-off-by: Adam Tkac <atkac@redhat.com>
|
|
With the use of the 'ntlm_auth' tool from the Samba project
|
|
|
|
Fix the return type of the callback to match close() and make use of it.
|
|
Introduced the initial setup to allow closesocket callbacks by making
sure sclose() is only ever called from one place in the libcurl source
and still run all test cases fine.
|
|
Made the public headers checksrc compliant
Removed types.h (it's been unused since April 2004)
Made the root makefile do make in include by default as well, so that
TAGS and the checksrc will work better.
|
|
closepolicy has been deprecated and unused for years
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
Introducing a few CURL_SOCKOPT* defines for conveniance. The new
CURL_SOCKOPT_ALREADY_CONNECTED signals to libcurl that the socket is to
be treated as already connected and thus it will skip the connect()
call.
|
|
|
|
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.
|
|
|
