If you invoke "curl http://example.com/a.htm http://example.com/b.htm", curl will only use a single connection.
Yes, but it will wait for Response A before sending Request B.
It probably isn't too obvious here, but yeah I know how it works =)
(I'm Daniel, who wrote the blog post discussed here and leads the curl development...)
To reproduce:
curl --libcurl 1.c http://example.com/a.htm http://example.com/b.htm
grep curl_multi_init 1.c
Here is how RFC 7230 defines "HTTP/1.1 pipelining":
"6.3.2. Pipelining
A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response)."
AFAIK, the curl binary does not do pipelining by this definition.
And, AFAIK, it will not generate code to do pipelining by invoking it with --libcurl.
Here is how RFC 7230 defines "HTTP/1.1 pipelining":
"6.3.2. Pipelining
A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response)."
AFAIK, the curl binary does not do pipelining.
And, AFAIK, it will not generate code to do pipelining by invoking it with --libcurl.
Imagine something like this with curl:
where curl only opens a single connection.Alas, AFAIK, pipelining is still not enabled in the curl binary.
As I understand it, the --libcurl option only generates code for what is possible with the curl binary, e.g., curl_easy_init(), curl_easy_setopt(), etc.
As such, it will not generate code using curl_multi_init(), curl_multi_setopt(), etc.
I have to automate the code generation myself.