README.pipelining: removed
All the details mentioned here are better documented in man pages
This commit is contained in:
parent
1c01cee601
commit
5fa82ca56f
@ -22,8 +22,8 @@
|
|||||||
AUTOMAKE_OPTIONS = foreign nostdinc
|
AUTOMAKE_OPTIONS = foreign nostdinc
|
||||||
|
|
||||||
DOCS = README.encoding README.memoryleak README.ares README.curlx \
|
DOCS = README.encoding README.memoryleak README.ares README.curlx \
|
||||||
README.hostip README.multi_socket README.httpauth README.pipelining \
|
README.hostip README.multi_socket README.httpauth README.curl_off_t \
|
||||||
README.curl_off_t README.pingpong
|
README.pingpong
|
||||||
|
|
||||||
CMAKE_DIST = CMakeLists.txt curl_config.h.cmake
|
CMAKE_DIST = CMakeLists.txt curl_config.h.cmake
|
||||||
|
|
||||||
|
@ -1,44 +0,0 @@
|
|||||||
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.
|
|
Loading…
x
Reference in New Issue
Block a user