- Aug 27, 2013
-
-
Daniel Stenberg authored
Without this, test 165 triggers a valgrind error when ran with curl_easy_perform_ev
-
Daniel Stenberg authored
When waiting for a 100-continue response from the server, the Curl_readwrite() will refuse to run if called until the timeout has been reached. We timeout code in multi_socket() allows code to run slightly before the actual timeout time, so for test 154 it could lead to the function being executed but refused in Curl_readwrite() and then the application would just sit idling forever. This was detected with runtests.pl -e on test 154.
-
Steve Holme authored
-
Steve Holme authored
warning: implicit declaration of function 'checkpasswd'
-
Steve Holme authored
Moved the calls to checkpasswd() out of the getparameter() function which allows for any related arguments to be specified on the command line before or after --user (and --proxy-user). For example: --bearer doesn't need to be specified before --user to prevent curl from asking for an unnecessary password as is the case with commit e7dcc454.
-
- Aug 26, 2013
-
-
Steve Holme authored
-
Kyle L. Huff authored
Added the --bearer option to the help output
-
Kyle L. Huff authored
Added the ability to specify an XOAUTH2 bearer token [RFC6750] via the --bearer option. Example usage: curl --url "imaps://imap.gmail.com:993/INBOX/;UID=1" --ssl-reqd --bearer ya29.AHES6Z...OMfsHYI --user username@example.com
-
Steve Holme authored
warning: 'variable' may be used uninitialized in this function
-
Daniel Stenberg authored
I brought back security.h in commit bb552933. As we actually already found out back in 2005 in commit 62970da6, the file name security.h causes problems so I renamed it curl_sec.h instead.
-
Daniel Stenberg authored
The specified curl binary will then be used to verify the running server(s) instead of the development version. This is very useful in some cases when the development version fails to verify correctly as then the test case may not run at all. The actual test will still be run with the "normal" curl executable (unless the test case specifies something differently).
-
Kyle L. Huff authored
Added the ability to use an XOAUTH2 bearer token [RFC6750] with SMTP for authentication using RFC6749 "OAuth 2.0 Authorization Framework". The bearer token is expected to be valid for the user specified in conn->user. If CURLOPT_XOAUTH2_BEARER is defined and the connection has an advertised auth mechanism of "XOAUTH2", the user and access token are formatted as a base64 encoded string and sent to the server as "AUTH XOAUTH2 <bearer token>".
-
Kyle L. Huff authored
Added the ability to use an XOAUTH2 bearer token [RFC6750] with IMAP for authentication using RFC6749 "OAuth 2.0 Authorization Framework". The bearer token is expected to be valid for the user specified in conn->user. If CURLOPT_XOAUTH2_BEARER is defined and the connection has an advertised auth mechanism of "XOAUTH2", the user and access token are formatted as a base64 encoded string and sent to the server as "A001 AUTHENTICATE XOAUTH2 <bearer token>".
-
Steve Holme authored
ISO C forbids forward references to 'enum' types
-
- Aug 25, 2013
-
-
Daniel Stenberg authored
The old numbers would still redirect but who knows for how long...
-
Kyle L. Huff authored
Added the ability to specify an XOAUTH2 bearer token [RFC6750] via the option CURLOPT_XOAUTH2_BEARER for authentication using RFC6749 "OAuth 2.0 Authorization Framework".
-
Kyle L. Huff authored
Added the ability to generated a base64 encoded XOAUTH2 token containing: "user=<username>^Aauth=Bearer <bearer token>^A^A" as per RFC6749 "OAuth 2.0 Authorization Framework".
-
Daniel Stenberg authored
We've announced this pending removal for a long time and we've repeatedly asked if anyone would care or if anyone objects. Nobody has objected. It has probably not even been working for a good while since nobody has tested/used this code recently. The stuff in krb4.h that was generic enough to be used by other sources is now present in security.h
-
Daniel Stenberg authored
-
- Aug 24, 2013
-
-
Daniel Stenberg authored
Several language fixes. Several reformats that should make the HTML generation of this document look better. Reported-by: Dave Thompson
-
- Aug 23, 2013
-
-
Daniel Stenberg authored
-
- Aug 22, 2013
-
-
Daniel Stenberg authored
Make sure we always return CURLM_CALL_MULTI_PERFORM when we reach CURLM_STATE_DONE since the state is transient and it can very well continue executing as there is nothing to wait for. Bug: http://curl.haxx.se/mail/lib-2013-08/0211.html Reported-by: Yi Huang
-
Daniel Stenberg authored
Renamed to "enum curl_khtype" now. Will break compilation for programs that rely on the enum name. Bug: https://github.com/bagder/curl/pull/76 Reported-by: Shawn Landden
-
Daniel Stenberg authored
... this also makes sure that the progess callback gets called more often during TFTP transfers. Added test 1238 to verify. Bug: http://curl.haxx.se/bug/view.cgi?id=1269 Reported-by: Jo3
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
- Aug 21, 2013
-
-
Gisle Vanem authored
I build curl.exe (using MingW) with '-DCURLDEBUG' and by importing from libcurl.dll. Which means the new curl_easy_perform_ev() must be exported from libcurl.dll.
-
- Aug 20, 2013
-
-
Daniel Stenberg authored
Doing curl_multi_add_handle() on an easy handle that is already added to a multi handle now returns this error code. It previously returned CURLM_BAD_EASY_HANDLE for this condition.
-
Daniel Stenberg authored
The closure_handle is "owned" by the multi handle and it is unconditional so the setting up of it should be in the Curl_multi_handle function rather than curl_multi_add_handle.
-
Daniel Stenberg authored
As it is done unconditionally in multi_init() this code will never run!
-
Daniel Stenberg authored
This function is meant to work *exactly* as curl_easy_perform() but will use the event-based libcurl API internally instead of curl_multi_perform(). To avoid relying on an actual event-based library and to not use non-portable functions (like epoll or similar), there's a rather inefficient emulation layer implemented on top of Curl_poll() instead. There's currently some convenience logging done in curl_easy_perform_ev which helps when tracking down problems. They may be suitable to remove or change once things seem to be fine enough. curl has a new --test-event option when built with debug enabled that then uses curl_easy_perform_ev() instead of curl_easy_perform(). If built without debug, using --test-event will only output a warning message. NOTE: curl_easy_perform_ev() is not part if the public API on purpose. It is only present in debug builds of libcurl and MUST NOT be considered stable even then. Use it for libcurl-testing purposes only. runtests.pl now features an -e command line option that makes it use --test-event for all curl command line tests. The man page is updated.
-
Gisle Vanem authored
-
Daniel Stenberg authored
-
Jonathan Nieder authored
libcurl quietly truncates usernames, passwords, and options from before an '@' sign in a URL to 255 (= MAX_CURL_PASSWORD_LENGTH - 1) characters to fit in fixed-size buffers on the stack. Allocate a buffer large enough to fit the parsed fields on the fly instead to support longer passwords. After this change, there are no more uses of MAX_CURL_OPTIONS_LENGTH left, so stop defining that constant while at it. The hardcoded max username and password length constants, on the other hand, are still used in HTTP proxy credential handling (which this patch doesn't touch). Reported-by: Colby Ranger
-
Jonathan Nieder authored
Instead of nesting "if(success)" blocks and leaving the reader in suspense about what happens in the !success case, deal with failure cases early, usually with a simple goto to clean up and return from the function. No functional change intended. The main effect is to decrease the indentation of this function slightly.
-
Jonathan Nieder authored
libcurl truncates usernames, passwords, and options set with curl_easy_setopt to 255 (= MAX_CURL_PASSWORD_LENGTH - 1) characters. This doesn't affect the return value from curl_easy_setopt(), so from the caller's point of view, there is no sign anything strange has happened, except that authentication fails. For example: # Prepare a long (300-char) password. s=0123456789; s=$s$s$s$s$s$s$s$s$s$s; s=$s$s$s; # Start a server. nc -l -p 8888 | tee out & pid=$! # Tell curl to pass the password to the server. curl --user me:$s http://localhost:8888 & sleep 1; kill $pid # Extract the password. userpass=$( awk '/Authorization: Basic/ {print $3}' <out | tr -d '\r' | base64 -d ) password=${userpass#me:} echo ${#password} Expected result: 300 Actual result: 255 The fix is simple: allocate appropriately sized buffers on the heap instead of trying to squeeze the provided values into fixed-size on-stack buffers. Bug: http://bugs.debian.org/719856 Reported-by: Colby Ranger
-
Jonathan Nieder authored
libcurl truncates usernames and passwords it reads from .netrc to LOGINSIZE and PASSWORDSIZE (64) characters without any indication to the user, to ensure the values returned from Curl_parsenetrc fit in a caller-provided buffer. Fix the interface by passing back dynamically allocated buffers allocated to fit the user's input. The parser still relies on a 256-character buffer to read each line, though. So now you can include an ~246-character password in your .netrc, instead of the previous limit of 63 characters. Reported-by: Colby Ranger
-
Jonathan Nieder authored
This makes it possible to increase the size of the buffers when needed in later patches. No functional change yet.
-
Jonathan Nieder authored
Instead of remembering before each "return" statement which temporary allocations, if any, need to be freed, take care to set pointers to NULL when no longer needed and use a goto to a common block to exit the function and free all temporaries. No functional change intended. Currently the only temporary buffer in this function is "proxy" which is already correctly freed when appropriate, but there will be more soon.
-
Jonathan Nieder authored
Use appropriately sized buffers on the heap instead of fixed-size buffers on the stack, to allow for longer usernames and passwords. Callers never pass anything longer than MAX_CURL_USER_LENGTH (resp. MAX_CURL_PASSWORD_LENGTH), so no functional change inteded yet.
-