1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
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!
* curl-config --libs doesn't inlude ares stuff
* Doing resumed upload over HTTP does not work with '-C -', because curl
doesn't do a HEAD first to get the initial size. This needs to be done
manually for HTTP PUT resume to work, and then '-C [index]'.
* CURLOPT_USERPWD and CURLOPT_PROXYUSERPWD have no way of providing user names
that contain a colon. This can't be fixed easily in a backwards compatible
way without adding new options (and then, they should most probably allow
setting user name and password separately).
* libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that
such parts should be sent to the server as 'CWD ' (without an argument).
The only exception to this rule, is that we knowingly break this if the
empty part is first in the path, as then we use the double slashes to
indicate that the user wants to reach the root dir (this exception SHALL
remain even when this bug is fixed).
* 1) libcurl does a POST
2) receives a 100-continue
3) sends away the POST
Now, if nothing else is returned from the server, libcurl MUST return
CURLE_GOT_NOTHING, but it seems it returns CURLE_OK as it seems to count
the 100-continue reply as a good enough reply.
* libcurl doesn't treat the content-length of compressed data properly, as
it seems HTTP servers send the *uncompressed* length in that header and
libcurl thinks of it as the *compressed* lenght. Some explanations are here:
http://curl.haxx.se/mail/lib-2003-06/0146.html
* Downloading 0 (zero) bytes files over FTP will not create a zero byte file
locally, which is because libcurl doesn't call the write callback with zero
bytes. Explained here: http://curl.haxx.se/mail/archive-2003-04/0143.html
* Using CURLOPT_FAILONERROR (-f/--fail) will make authentication to stop
working if you use anything but plain Basic auth.
* IPv6 support on AIX 4.3.3 doesn't work due to a missing sockaddr_storage
struct. It has been reported to work on AIX 5.1 though.
* 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.
* The -m parameter does not work when using telnet with curl on Windows.
* 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>
|
