Hui Li | 26 Nov 02:08 2014

Help: Connection Time


I'm using curl to get all breakdown latency details via -w %{} pairs.
However, I don't know how those metrics calculated. For example, I got
following data while accessing

DNS Lookup Time: 0.004
Connect Time: 0.279
App Connect Time: 0.968
Redirect Time: 0.574
Pre Transfer Time: 0.968
Start Transfer Time: 1.254
Total Time: 2.079

So how 'Total Time' calculated? What's the relationship between each of
them? Can I get 'Total Time' based on above data?



List admin:
Sascha Ziemann | 24 Nov 17:17 2014

How to use keep-alive in a Bash co-process?

I need to download several files and I would like to use keep-alive, because it is an TSL connection and the connection establishment is quite slow. But I am not able to specify all URLs in the command line, because they depend on each other. The second URL gets calculated by the content of the first URL and so on. I would like to use curl in a co-process. I tried to open a pipe to curl -sSLK- in order to send url="" and output="" commands to curl. But curl does not start with the download. Instead it waits until the pipe gets closed. This prevents the calculation of the second URL, because the body of the first is never downloaded.

How can I tell curl to start immediately with the first download as soon as a url/output pair has been read from stdin?


List admin:
Igor Zhbanov | 22 Nov 16:51 2014

error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure


I have upgraded my server to OpenSuSE-13.2 and got following error:

$ curl -v

* Hostname was NOT found in DNS cache
*   Trying
* Connected to ( port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs/
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS alert, Server hello (2):
* error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert
handshake failure
* Closing connection 0
curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure

Is this problem with web-site's settings or with curl cyphers options?

$ curl --version

curl 7.38.0 (x86_64-suse-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1j
zlib/1.2.8 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
libz TLS-SRP

Thank you.
List admin:
Ingimar | 20 Nov 15:36 2014

curl post


I am trying to post an array-list to a restful-service which I created.
I am able doing this by using JSON, my method is annotated :  <at> Consumes(MediaType.APPLICATION_JSON) 

as in:
 curl -i -X POST -H 'Content-Type: application/json' -d '{"list":["key1:val1","key2:val2"]}' http://localhost:8080/MediaServerResteasy/media/testing

I would like to be able to post from a HTML-FORM.
I changes the annotation on my restful to :
<at> Consumes(MediaType.MULTIPART_FORM_DATA)

Check out the following:

did try the following :
curl -X POST -H "Content-Type:multipart/form-data" -F 'taglist[]=key1:value1' -F 'taglist[]=key2:value2'  http://localhost:8080/MediaServerResteasy/media/testing

curl -X POST -H "Content-Type:multipart/form-data" -F 'taglist=key1:value1' -F 'taglist=key2:value2'  http://localhost:8080/MediaServerResteasy/media/testing

but neither is working.
What am I doing wrong here ?

My Java-form looks like this:
<at> FormParam("taglist")
    private List<String> taglist;

    public List<String> getTaglist() {
        return taglist;

    public void setTaglist(List<String> taglist) {
        this.taglist = taglist;

Regards, i
List admin:
Charles Pritchard | 20 Nov 02:30 2014

Sending an unbuffered PUT without chunked encoding

How would I signal to CURL that I want to PUT data from STDIN without using chunked encoding and without buffering?

Currently, -T triggers chunked encoding, I don't want that.

I already know the content length ahead of time, so I don't need curl buffering the full data into memory as it does with --data-binary <at> -.

List admin:
Rayston | 17 Nov 22:07 2014

socket connection, waiting for ENQ

Is there a way from the curl command line tool to open a connection, wait for an ENQ response and then send data in a file?
List admin:
Jemiolo, John | 6 Nov 17:10 2014

curl ipv6 command line questions

I have been trying to sort out communicating with a system on a private network from a SLES11 SP3 Linux host using: curl 7.38
What I have found was
curl  -x “”   --interface eth1  http://<IPv4 Address>/path    ß works for IPv4
curl  -x “” http://[IPv6 Address%25eth1]/path   ßworks for IPv6
curl  -x “”   --interface eth1  http://[IPv6 Address]/path  ßDOES NOT WORK for IPV6  seems to just hang forever.
Now why “%25eth1”  works I do not know, I cannot find this usage in any of the curl doc’s  (I tried this because I use this ssh’ing to ipv6 hosts.
Also why does “ –interface  eth1  “ work for IPv4  and not IPv6?
Also the “–g” option,   its use seems not to have any effect when using IPv6 addresses, what is its correct usage?
Am I missing something?
List admin:
narkedimilly navya | 6 Nov 10:00 2014

Extra colon is observed while downloading certificates from LDAP using CURL 7.37 version.

Hi All,

We are getting extra colon while downloading the certificates from LDAP using CURL 7.37 where as we didn`t see this "::" with old
version of curl (7.37).
can you please suggest why is this change present between the CURL 7.35 and CURL 7.37 versions.

while using curl 7.35 version :
rpm -qa | grep curl
curl -k -o /tmp/rootca.pem --url "ldap://<ip/port>/dc=generic,dc=com?cACertificate?sub?(CN=Generic_Root_CA)" -m 60
[root <at> BLR7INST3-nib-9 ~]# cat /tmp/rootca.pem
DN: CN=Generic_Root_CA,O=Generic,dc=generic,dc=com
while using Curl 7.37 version :

rpm -qa | grep curl
curl -k -o /tmp/rootca.pem --url "ldap://<ip/port>/dc=generic,dc=com?cACertificate?sub?(CN=Generic_Root_CA)" -m 60
[root <at> BLR7INST1-nib-1 ~]# cat /tmp/rootca.pem | grep binary

List admin:
Daniel Stenberg | 5 Nov 08:58 2014

[SECURITY ADVISORY] libcurl duphandle read out of bounds

libcurl duphandle read out of bounds

Project cURL Security Advisory, November 5th 2014 -


libcurl's function
has a bug that can lead to libcurl eventually sending off sensitive data that
was not intended for sending.

When doing an HTTP POST transfer with libcurl, you can use the 
`CURLOPT_COPYPOSTFIELDS` option to specify a memory area holding the data to 
send to the remote server. The memory area's size is set with a separate 
option, for example `CURLOPT_POSTFIELDSIZE`.

As the name implies, the data in the specified buffer is copied to a privately 
held memory buffer that libcurl allocates on the heap. The memory area is 
associated with the common CURL handle, often referred to as an "easy handle".

This handle can be duplicated by an application to create an identical copy, 
and all the already set options and data is then also similarly cloned and 
will be associated with the newly returned handle. This also includes the data 
to send in an HTTP POST request.

The internal libcurl function that duplicates options from the old handle to
the new had two problems:

1. It mistakenly treated the post data buffer as if it was a C string which is
    assumed to end with a zero byte. strdup() was subsequently used to
    duplicate the post data buffer, and as a post data buffer can both
    legitimately contain a zero byte, or may not contain any zero bytes at all
    (including a tailing one), strdup() could create a copy that a) was too
    small b) was too large or c) could crash due to reading an inaccessible
    memory area. The strdup() function of course allocates memory off the heap.

2. After duplication of the handle data, the pointer used to read from when
    sending the data was not updated. So when sending off the post, libcurl
    would still read from the original handle's buffer which at that time could
    have been freed or reused for other purposes.

When libcurl subsequently constructs the HTTP POST request and includes data
for the protocol body it will memcpy() data from that pointer using the old
size and the old pointer. This makes a read from the wrong place and can lead
to libcurl inserting data into the request that happens to be stored at that
places in memory at that time.

We are not aware of anyone having been able to actually exploit this for
nefarious purposes, but we can't exclude that it is possible or even might
already have been exploited.


This bug requires `CURLOPT_COPYPOSTFIELDS` and `curl_easy_duphandle()` to be
used in that order, and then the duplicate handle must be used to perform the

The curl tool is not affected, it does not use this sequence.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name
CVE-2014-3707 to this issue.


This bug has existed since `CURLOPT_COPYPOSTFIELDS` was introduced.

- Affected versions: from libcurl 7.17.1 to and including 7.38.0
- Not affected versions: libcurl >= 7.39.0

libcurl is used by many applications, but not always advertised as such!


libcurl 7.39.0 makes sure that the buffer area is duplicated and presumed to
be binary.

A patch for this problem is available at:


We suggest you take one of the following actions immediately, in order of

A - Upgrade to curl and libcurl 7.39.0

B - Apply the patch and rebuild libcurl

C - Avoid using `CURLOPT_COPYPOSTFIELDS` then `curl_easy_duphandle()`

If you are using PHP/CURL, we advice you to avoid `curl_copy_handle()` after


It was first reported to the curl project on September 16th 2014.

We contacted distros <at> openwall on October 20.

libcurl 7.39.0 was released on November 5th 2014, coordinated with the
publication of this advisory.


Reported by Symeon Paraschoudis. Stas Malyshev helped us understand and repeat
the problem. Dan Fandrich helped assess the security risk. Tomas Hoger
analyzed the second part of the bug. Patch written by Daniel Stenberg.

Thanks a lot!



List admin:
George | 4 Nov 17:06 2014

curl not using tls even if told to do so


I am trying to connect to a remote host using curl. The remote host
supports only tlsv1.2 and the RC4-SHA cipher. It does not support NSS,
only OpenSSL.

The default curl that comes with CentOS 7(the one I am using) was
using NSS so that didn't work for me.

Now I got the latest curl from git and manually compiled it with
support of openssl and without nss. My curl -V output is:
curl 7.38.1-DEV (x86_64-unknown-linux-gnu) libcurl/7.38.1-DEV
OpenSSL/1.0.1e zlib/1.2.7 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s
rtsp scp sftp smtp smtps telnet tftp
Features: IPv6 Largefile NTLM NTLM_WB SSL libz

I am running curl like this:
/usr/local/bin/curl -v --tlsv1.2 --cipher RC4-SHA --key ./somekey.pem
--cert ./somecert.crt

But the strange thing is that from the verbose output I can see that
curl is still trying to connect with SSLv3 which is not available:
* Hostname was NOT found in DNS cache
*   Trying
* Connected to ( port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS handshake, CERT verify (15):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
* Closing connection 0
curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert
handshake failure

So why does curl refuse to use tlsv1.2 even if told to do so?

Please help
List admin:
John Goebel | 3 Nov 20:43 2014

Building cURL passing the -R option to linker

On Ubuntu 10.04 (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1)) passing 
the -R option using LDFLAGS works.
CPPFLAGS="-I/opt/openssl/include" LDFLAGS="-L/opt/openssl/lib" 
LDFLAGS="-R/opt/openssl/lib" ./configure --with-ssl=/opt/openssl 
gcc 4.4.3 reported "unrecognized option '-R/opt/openssl/lib'" but continued.

On Ubuntu 12.04 (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)) 
configure failed with error "configure: error: C compiler cannot create 
gcc 4.6.3 reported "gcc: error: unrecognized option '-R'" and then 
terminated. configure failed with " C compiler cannot create executables".

The solution is to not pass 'LDFLAGS="-R/opt/openssl/lib"', replace it 
with '-Xlinker -rpath=/opt/openssl/lib"'.
CPPFLAGS="-I/opt/openssl/include" LDFLAGS="-L/opt/openssl/lib -Xlinker 
-rpath=/opt/openssl/lib" ./configure --with-ssl=/opt/openssl 

I don't know if this is an Ubuntu oddity, or if there is a better 
solution. In any even it worked for me, and perhaps should be added to 
the INSTALL file.

John Goebel
List admin: