git-svn-id: svn://10.65.10.50/branches/R_10_00@23289 c028cbd2-c16b-5b4b-a496-9718f37d4682
		
			
				
	
	
		
			45 lines
		
	
	
		
			1.8 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			45 lines
		
	
	
		
			1.8 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
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.
 |