87 lines
		
	
	
		
			3.7 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			87 lines
		
	
	
		
			3.7 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
These are problems known to exist at the time of this release. Feel free to
 | 
						|
join in and help us correct one or more of these! Also be sure to check the
 | 
						|
changelog of the current development status, as one or more of these problems
 | 
						|
may have been fixed since this was written!
 | 
						|
 | 
						|
* Running 'make test' on Mac OS X gives 4 errors. This seems to be related
 | 
						|
  to some kind of libtool problem:
 | 
						|
  http://curl.haxx.se/mail/archive-2002-03/0029.html and
 | 
						|
  http://curl.haxx.se/mail/archive-2002-03/0033.html
 | 
						|
 | 
						|
* libcurl does not deal nicely with files larger than 2GB
 | 
						|
 | 
						|
* GOPHER transfers seem broken
 | 
						|
 | 
						|
* configure --disable-http is not fully supported. All other protocols seem
 | 
						|
  to work to disable.
 | 
						|
 | 
						|
* If a HTTP server responds to a HEAD request and includes a body (thus
 | 
						|
  violating the RFC2616), curl won't wait to read the response but just stop
 | 
						|
  reading and return back. If a second request (let's assume a GET) is then
 | 
						|
  immediately made to the same server again, the connection will be re-used
 | 
						|
  fine of course, and the second request will be sent off but when the
 | 
						|
  response is to get read, the previous response-body is what curl will read
 | 
						|
  and havoc is what happens.
 | 
						|
  More details on this is found in this libcurl mailing list thread:
 | 
						|
  http://curl.haxx.se/mail/lib-2002-08/0000.html
 | 
						|
 | 
						|
------------------------------------------------------------------------------
 | 
						|
 | 
						|
Q: My program blows up when I run lots of curl_easy_perform() calls on a
 | 
						|
single thread
 | 
						|
Q: My program dies when a single thread re-enters the win32 select() call
 | 
						|
via curl_easy_perform()
 | 
						|
Q: --- add your own flavour here ---
 | 
						|
 | 
						|
Single Threaded Re-Entracy
 | 
						|
--------------------------
 | 
						|
 | 
						|
There is a glitch / trick to using cURL on Win32 related to re-entrancy.
 | 
						|
This experience was gained on verion 7.9.4 using Windows NT SP3 in a banking
 | 
						|
environment (just in case you wanted to know).
 | 
						|
 | 
						|
If you have already called curl_easy_perform(), and *somehow* you cause your
 | 
						|
single thread of execution to make another call to curl_easy_perform() - the
 | 
						|
windows socket() call used to create a new socket for the second connection
 | 
						|
can return with 10044 / 10043 error codes.
 | 
						|
 | 
						|
The WSA errors we experienced are:
 | 
						|
WSAEPROTONOSUPPORT 
 | 
						|
(10043) 
 | 
						|
Protocol not supported. 
 | 
						|
The requested protocol has not been configured into the system, or no
 | 
						|
implementation for it exists. For example, a socket call requests a
 | 
						|
SOCK_DGRAM socket, but specifies a stream protocol. 
 | 
						|
 | 
						|
WSAESOCKTNOSUPPORT 
 | 
						|
(10044) 
 | 
						|
Socket type not supported. 
 | 
						|
The support for the specified socket type does not exist in this address
 | 
						|
family. For example, the optional type SOCK_RAW might be selected in a
 | 
						|
socket call, and the implementation does not support SOCK_RAW sockets at
 | 
						|
all. 
 | 
						|
 | 
						|
We have experienced this by creating a timer that ticks every 20ms, and on
 | 
						|
the tick making a curl_easy_perform() call.  The call usually completed in
 | 
						|
about 300ms.  And we expected (before this test) that the timer would NOT be
 | 
						|
fired during a call to curl_easy_perform(), howvever, while the first
 | 
						|
curl_easy_perform() is running a tick *is* fired by the windows API somehow,
 | 
						|
and we then call curl_easy_perform() again - thus single threaded
 | 
						|
re-entrancy is achieved.
 | 
						|
 | 
						|
Notes:
 | 
						|
* We made sure that a new CURL structure was being used for each
 | 
						|
curl_easy_perform() request, and that the curl_global_init() had been called
 | 
						|
beforehand.  
 | 
						|
* I'm happy to answer any questions about this problem to try to track it
 | 
						|
down.
 | 
						|
* Once the socket() call started failing, there is no hope - it never works
 | 
						|
again.
 | 
						|
* Slowing the timer down to give each request enough time to complete solves
 | 
						|
this problem completely.
 | 
						|
 | 
						|
If anyone has the source code to the WinNT implementation of socket() and
 | 
						|
can figure out WHY this can occur, more tracing can be performed.
 | 
						|
 | 
						|
        John Clayton <John.Clayton at barclayscapital.com>
 |