The ability to do HTTP requests over a UNIX domain socket has been
requested before, in Apr 2008 [0][1] and Sep 2010 [2]. While a
discussion happened, no patch seems to get through. I decided to give it
a go since I need to test a nginx HTTP server which listens on a UNIX
domain socket.
One patch [3] seems to make it possible to use the
CURLOPT_OPENSOCKETFUNCTION function to gain a UNIX domain socket.
Another person wrote a Go program which can do HTTP over a UNIX socket
for Docker[4] which uses a special URL scheme (though the name contains
cURL, it has no relation to the cURL library).
This patch considers support for UNIX domain sockets at the same level
as HTTP proxies / IPv6, it acts as an intermediate socket provider and
not as a separate protocol. Since this feature affects network
operations, a new feature flag was added ("unix-sockets") with a
corresponding CURL_VERSION_UNIX_SOCKETS macro.
A new CURLOPT_UNIX_SOCKET_PATH option is added and documented. This
option enables UNIX domain sockets support for all requests on the
handle (replacing IP sockets and skipping proxies).
A new configure option (--enable-unix-sockets) and CMake option
(ENABLE_UNIX_SOCKETS) can disable this optional feature. Note that I
deliberately did not mark this feature as advanced, this is a
feature/component that should easily be available.
[0]: http://curl.haxx.se/mail/lib-2008-04/0279.html
[1]: http://daniel.haxx.se/blog/2008/04/14/http-over-unix-domain-sockets/
[2]: http://sourceforge.net/p/curl/feature-requests/53/
[3]: http://curl.haxx.se/mail/lib-2008-04/0361.html
[4]: https://github.com/Soulou/curl-unix-socket
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
HTTP Pipelining with libcurl
============================
Background
Since pipelining implies that one or more requests are sent to a server before
the previous response(s) have been received, we only support it for multi
interface use.
Considerations
When using the multi interface, you create one easy handle for each transfer.
Bascially any number of handles can be created, added and used with the multi
interface - simultaneously. It is an interface designed to allow many
simultaneous transfers while still using a single thread. Pipelining does not
change any of these details.
API
We've added a new option to curl_multi_setopt() called CURLMOPT_PIPELINING
that enables "attempted pipelining" and then all easy handles used on that
handle will attempt to use an existing pipeline.
Details
- A pipeline is only created if a previous connection exists to the same IP
address that the new request is being made to use.
- Pipelines are only supported for HTTP(S) as no other currently supported
protocol has features resemembling this, but we still name this feature
plain 'pipelining' to possibly one day support it for other protocols as
well.
- HTTP Pipelining is for GET and HEAD requests only.
- When a pipeline is in use, we must take precautions so that when used easy
handles (i.e those who still wait for a response) are removed from the multi
handle, we must deal with the outstanding response nicely.
- Explicitly asking for pipelining handle X and handle Y won't be supported.
It isn't easy for an app to do this association. The lib should probably
still resolve the second one properly to make sure that they actually _can_
be considered for pipelining. Also, asking for explicit pipelining on handle
X may be tricky when handle X get a closed connection.
970c22f970