[aplorbust]

It wasnt until 2006 that curl added HTTP/1.1 pipelining support. Hence I always used netcat instead of curl because I utilised pipelining heavily for text/html retrieval (IME, most servers supported it).

Imagine something like this with curl:

   curl << eof
   http://example.com/a.htm
   http://example.com/b.htm
   eof

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.

[bagder]

If you invoke "curl http://example.com/a.htm http://example.com/b.htm", curl will only use a single connection.

[lpgauth]

Yes, but it will wait for Response A before sending Request B.

[bagder]

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...)

[aplorbust]

To reproduce:

   curl --libcurl 1.c http://example.com/a.htm http://example.com/b.htm

   grep curl_multi_init 1.c

https://curl.haxx.se/mail/archive-2008-02/0036.html

[aplorbust]

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.

[aplorbust]

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.