On 10 January 2014 22:42, caballist caballist
caball...@acclaimsystems.eu wrote:
The code appears to assume that the ALARM signal will be handled on the
thread calling Curl_resolv_timeout (and there are comments noting that the
rest of the application will be run from within a signal handler).
Le 12 janv. 2014 à 00:19, Daniel Stenberg dan...@haxx.se a écrit :
The question is: should we prevent libcurl to send the request by failing
early?
Yes I think so. Sending -1 is plain wrong.
After a quick code review I have several questions I would like to discuss:
I compared what
Daniel Stenberg wrote:
On Sat, 11 Jan 2014, Cédric Deltheil wrote:
When performing a standard HTTP POST (w/o chunked encoding) with a custom
read function, a common mistake is to forget to explicitly set the POST
size via `CURLOPT_POSTFIELDSIZE`.
This results in libcurl sending a negative
Am 09.01.2014 23:34, schrieb Daniel Stenberg:
Left to do is then to build curl with other TLS backends and try it
against https://www.howsmyssl.com/a/check to see if there are more
flaws in this style.
WinSSL on Windows 7 SP1 looks okay:
$ src/curl -v https://www.howsmyssl.com/a/check;
*
On Sun, 12 Jan 2014, Marc Hörsken wrote:
WinSSL on Windows 7 SP1 looks okay:
Yes, cipher wise at least. I figure this is less good:
beast_vuln:true,
tls_version:TLS 1.0
And they are what makes the site deems this to get:
rating:Bad}
... but I don't think we can change that with this
