curl/lib
Daniel Stenberg a865bd9fba IsPipeliningPossible: only for HTTP
The function that checks if pipelining is possible now requires the HTTP
bit to be set so that it doesn't mistakenly tries to do it for other
protocols.

Bug: http://curl.haxx.se/mail/lib-2010-12/0152.html
Reported by: Dmitri Shubin
2010-12-13 13:44:50 +01:00
..
.gitignore
amigaos.c
amigaos.h
arpa_telnet.h
base64.c
CMakeLists.txt
config-amigaos.h
config-dos.h
config-mac.h
config-os400.h
config-riscos.h
config-symbian.h
config-tpf.h
config-vms.h
config-vxworks.h
config-win32.h
config-win32ce.h
connect.c
connect.h
content_encoding.c
content_encoding.h
cookie.c
cookie.h
curl_addrinfo.c
curl_addrinfo.h
curl_base64.h
curl_config.h.cmake
curl_fnmatch.c
curl_fnmatch.h
curl_gethostname.c
curl_gethostname.h
curl_hmac.h
curl_ldap.h
curl_md4.h
curl_md5.h
curl_memory.h
curl_memrchr.c
curl_memrchr.h
curl_rand.c
curl_rand.h
curl_rtmp.c disconnect: pass on the dead_connection argument 2010-12-06 15:33:38 +01:00
curl_rtmp.h
curl_sspi.c
curl_sspi.h
curl_threads.c
curl_threads.h
curlx.h
dict.c
dict.h
easy.c easy: fix compiler warning: end-of-loop code not reached 2010-12-07 03:27:59 +01:00
easyif.h
escape.c
escape.h
file.c
file.h
fileinfo.c
fileinfo.h
firefox-db2pem.sh
formdata.c
formdata.h
ftp.c url: provide dead_connection flag in Curl_handler::disconnect 2010-12-06 14:35:42 +01:00
ftp.h
ftplistparser.c
ftplistparser.h
getenv.c
getinfo.c
getinfo.h
gopher.c
gopher.h
gtls.c
gtls.h
hash.c
hash.h
hmac.c
hostares.c Curl_wait_for_resolv: correct timeout 2010-12-05 23:39:41 +01:00
hostasyn.c
hostip4.c
hostip6.c
hostip.c
hostip.h
hostsyn.c
hostthre.c
http_chunks.c
http_chunks.h
http_digest.c
http_digest.h
http_negotiate.c
http_negotiate.h
http_ntlm.c
http_ntlm.h
http.c
http.h
if2ip.c
if2ip.h
imap.c url: provide dead_connection flag in Curl_handler::disconnect 2010-12-06 14:35:42 +01:00
imap.h
inet_ntop.c
inet_ntop.h
inet_pton.c
inet_pton.h
krb4.c
krb4.h
krb5.c
ldap.c
libcurl.def
libcurl.imp
libcurl.plist
libcurl.rc
llist.c
llist.h
Makefile.am
makefile.amiga
Makefile.b32
makefile.dj
Makefile.inc
Makefile.m32 Updated OpenSSL version. 2010-12-05 10:59:58 +01:00
Makefile.netware Updated OpenSSL version. 2010-12-05 10:59:58 +01:00
Makefile.vc6
Makefile.vxworks
Makefile.Watcom Updated OpenSSL version. 2010-12-05 10:59:58 +01:00
md4.c
md5.c
memdebug.c
memdebug.h
mk-ca-bundle.pl
mk-ca-bundle.vbs
mprintf.c
msvcproj.foot
msvcproj.head
multi.c multi_runsingle: don't timeout completed handles 2010-12-13 12:51:48 +01:00
multiif.h
netrc.c
netrc.h
nonblock.c
nonblock.h
nss.c
nssg.h
nwlib.c
nwos.c
openldap.c url: provide dead_connection flag in Curl_handler::disconnect 2010-12-06 14:35:42 +01:00
parsedate.c
parsedate.h
pingpong.c
pingpong.h
polarssl.c
polarssl.h
pop3.c url: provide dead_connection flag in Curl_handler::disconnect 2010-12-06 14:35:42 +01:00
pop3.h
progress.c
progress.h
qssl.c
qssl.h
rawstr.c
rawstr.h
README.ares
README.curl_off_t
README.curlx
README.encoding
README.hostip
README.httpauth
README.memoryleak
README.multi_socket
README.pingpong
README.pipelining
rtsp.c url: provide dead_connection flag in Curl_handler::disconnect 2010-12-06 14:35:42 +01:00
rtsp.h url: provide dead_connection flag in Curl_handler::disconnect 2010-12-06 14:35:42 +01:00
security.c
select.c
select.h
sendf.c Curl_send/recv_plain: return errno on failure 2010-12-05 23:04:11 +01:00
sendf.h
setup_once.h
setup-os400.h
setup.h
share.c
share.h
slist.c remove the CVSish $Id$ lines 2010-03-24 11:02:54 +01:00
slist.h
smtp.c url: provide dead_connection flag in Curl_handler::disconnect 2010-12-06 14:35:42 +01:00
smtp.h
sockaddr.h
socks_gssapi.c
socks_sspi.c
socks.c
socks.h
speedcheck.c
speedcheck.h
splay.c
splay.h
ssh.c url: provide dead_connection flag in Curl_handler::disconnect 2010-12-06 14:35:42 +01:00
ssh.h
sslgen.c
sslgen.h
ssluse.c ossl_connect_common: detect connection re-use 2010-12-06 14:41:18 +01:00
ssluse.h
strdup.c
strdup.h
strequal.c
strequal.h
strerror.c
strerror.h
strtok.c
strtok.h
strtoofft.c
strtoofft.h
telnet.c
telnet.h
tftp.c url: provide dead_connection flag in Curl_handler::disconnect 2010-12-06 14:35:42 +01:00
tftp.h
timeval.c
timeval.h
transfer.c url: provide dead_connection flag in Curl_handler::disconnect 2010-12-06 14:35:42 +01:00
transfer.h
url.c IsPipeliningPossible: only for HTTP 2010-12-13 13:44:50 +01:00
url.h url: provide dead_connection flag in Curl_handler::disconnect 2010-12-06 14:35:42 +01:00
urldata.h url: provide dead_connection flag in Curl_handler::disconnect 2010-12-06 14:35:42 +01:00
vc6libcurl.dsw
vc8proj.foot
vc8proj.head
version.c
warnless.c
warnless.h
wildcard.c
wildcard.h

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.

- We need options to control max pipeline length, and probably how to behave
  if we reach that limit. As was discussed on the list, it can probably be
  made very complicated, so perhaps we can think of a way to pass all
  variables involved to a callback and let the application decide how to act
  in specific situations. Either way, these fancy options are only interesting
  to work on when everything is working and we have working apps to test with.