- Mar 20, 2015
-
-
Daniel Stenberg authored
-
- Mar 19, 2015
-
-
Dan Fandrich authored
This change was made in CyaSSL/WolfSSL ver. 3.4.0
-
Daniel Stenberg authored
We prematurely changed protocol handler to HTTP/2 which made things very slow (and wrong). Reported-by: Stefan Eissing Bug: https://github.com/bagder/curl/issues/169
-
Dan Fandrich authored
-
Daniel Stenberg authored
Coverity CID 1288826
-
- Mar 18, 2015
-
-
Dan Fandrich authored
-
Dan Fandrich authored
If a man page exists in the opts/ directory, it must also be referenced either in curl_easy_setopt.3 or curl_multi_setopt.3
-
Dan Fandrich authored
-
Kamil Dudka authored
... if disabled at libcurl level. Otherwise, we would allow to negotiate NPN despite curl was invoked with the --no-npn option.
-
Jay Satiro authored
- Get rid of this flood of warnings in Windows mingw build: warning: missing terminating " character The warning is due to the carriage return. When msysgit checks out files from the repo by default it converts the line endings to CRLF. Prior to this change when mkhelp.pl processed the MANUAL and curl.1 in CRLF format the trailing carriage returns caused unnecessary CR in the output.
-
Daniel Stenberg authored
-
Christian Weisgerber authored
Using $< in a non-suffix rule context is a GNU make idiom. This bug was introduced in 7.41.0.
-
- Mar 17, 2015
-
-
Dan Fandrich authored
-
Stefan Bühler authored
-
Daniel Stenberg authored
Reported-by: Stefan Eissing Bug: https://github.com/bagder/curl/issues/169
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
- Mar 16, 2015
-
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
Since we just started make use of free(NULL) in order to simplify code, this change takes it a step further and: - converts lots of Curl_safefree() calls to good old free() - makes Curl_safefree() not check the pointer before free() The (new) rule of thumb is: if you really want a function call that frees a pointer and then assigns it to NULL, then use Curl_safefree(). But we will prefer just using free() from now on.
-
Markus Elfring authored
The following functions return immediately if a null pointer was passed. * Curl_cookie_cleanup * curl_formfree It is therefore not needed that a function caller repeats a corresponding check. This issue was fixed by using the software Coccinelle 1.0.0-rc24. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
-
Markus Elfring authored
The function "free" is documented in the way that no action shall occur for a passed null pointer. It is therefore not needed that a function caller repeats a corresponding check. http://stackoverflow.com/questions/18775608/free-a-null-pointer-anyway-or-check-first This issue was fixed by using the software Coccinelle 1.0.0-rc24. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
-
Jay Satiro authored
Bug: https://github.com/bagder/curl/pull/168 (trynextip) - Don't try the "other" protocol family unless IPv6 is available. In an IPv4-only build the other family can only be IPv6 which is unavailable. This change essentially stops IPv4-only builds from attempting the "happy eyeballs" secondary parallel connection that is supposed to be used by the "other" address family. Prior to this change in IPv4-only builds that secondary parallel connection attempt could be erroneously used by the same family (IPv4) which caused a bug where every address after the first for a host could be tried twice, often in parallel. This change fixes that bug. An example of the bug is shown below. Assume MTEST resolves to 3 addresses 127.0.0.2, 127.0.0.3 and 127.0.0.4: * STATE: INIT => CONNECT handle 0x64f4b0; line 1046 (connection #-5000) * Rebuilt URL to: http://MTEST/ * Added connection 0. The cache now contains 1 members * STATE: CONNECT => WAITRESOLVE handle 0x64f4b0; line 1083 (connection #0) * Trying 127.0.0.2... * STATE: WAITRESOLVE => WAITCONNECT handle 0x64f4b0; line 1163 (connection #0) * Trying 127.0.0.3... * connect to 127.0.0.2 port 80 failed: Connection refused * Trying 127.0.0.3... * connect to 127.0.0.3 port 80 failed: Connection refused * Trying 127.0.0.4... * connect to 127.0.0.3 port 80 failed: Connection refused * Trying 127.0.0.4... * connect to 127.0.0.4 port 80 failed: Connection refused * connect to 127.0.0.4 port 80 failed: Connection refused * Failed to connect to MTEST port 80: Connection refused * Closing connection 0 * The cache now contains 0 members * Expire cleared curl: (7) Failed to connect to MTEST port 80: Connection refused The bug was born in commit bagder/curl@2d435c7.
-
- Mar 15, 2015
-
-
Daniel Stenberg authored
-
Frank Meier authored
In function Curl_closesocket() in connect.c the call to Curl_multi_closed() was wrongly omitted if a socket close function (CURLOPT_CLOSESOCKETFUNCTION) is registered. That would lead to not removing the socket from the internal hash table and not calling the multi socket callback appropriately. Bug: http://curl.haxx.se/bug/view.cgi?id=1493
-
- Mar 14, 2015
-
-
Tobias Stoeckmann authored
A signal handler for SIGALRM is installed in Curl_resolv_timeout. It is configured to interrupt system calls and uses siglongjmp to return into the function if alarm() goes off. The signal handler is installed before curl_jmpenv is initialized. This means that an already installed alarm timer could trigger the newly installed signal handler, leading to undefined behavior when it accesses the uninitialized curl_jmpenv. Even if there is no previously installed alarm available, the code in Curl_resolv_timeout itself installs an alarm before the environment is fully set up. If the process is sent into suspend right after that, the signal handler could be called too early as in previous scenario. To fix this, the signal handler should only be installed and the alarm timer only be set after sigsetjmp has been called.
-
Daniel Stenberg authored
... by using the regular Curl_http_done() method which checks for that. This makes test 1801 fail consistently with error 56 (which seems fine) to that test is also updated here. Reported-by: Ben Darnell Bug: https://github.com/bagder/curl/issues/166
-
- Mar 13, 2015
-
-
Dan Fandrich authored
Required for the test to work after a5d99494.
-
- Mar 12, 2015
-
-
Daniel Stenberg authored
-
Daniel Stenberg authored
While the previous string worked, this is the documented format. Reported-by: Richard Moore
-
Daniel Stenberg authored
This makes curl pick better (stronger) ciphers by default. The strongest available ciphers are fine according to the HTTP/2 spec so an OpenSSL built curl is no longer rejected by string HTTP/2 servers. Bug: http://curl.haxx.se/bug/view.cgi?id=1487
-
Fabian Keil authored
Required for the tests to work after a5d99494.
-