mirror of
https://github.com/moparisthebest/curl
synced 2024-12-22 08:08:50 -05:00
123 lines
5.5 KiB
Plaintext
123 lines
5.5 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!
|
|
|
|
* 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>
|