2002-03-07 03:29:24 -05:00
|
|
|
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!
|
|
|
|
|
|
2004-03-15 11:32:13 -05:00
|
|
|
* NTLM authentication with passwords longer than 14 letters fail. There is
|
|
|
|
|
a known fix for this, planned to come in curl 7.11.2
|
|
|
|
|
|
2003-11-12 09:33:58 -05:00
|
|
|
* 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]'.
|
|
|
|
|
|
2003-10-21 02:06:32 -04:00
|
|
|
* 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).
|
|
|
|
|
|
2003-10-17 08:21:48 -04:00
|
|
|
* 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).
|
|
|
|
|
|
2003-10-17 07:36:41 -04:00
|
|
|
* 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.
|
|
|
|
|
|
2003-08-11 11:15:25 -04:00
|
|
|
* 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
|
|
|
|
|
|
2003-08-05 08:32:02 -04:00
|
|
|
* Using CURLOPT_FAILONERROR (-f/--fail) will make authentication to stop
|
|
|
|
|
working if you use anything but plain Basic auth.
|
|
|
|
|
|
2003-05-16 06:57:53 -04:00
|
|
|
* 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.
|
|
|
|
|
|
2002-03-18 03:52:15 -05:00
|
|
|
* GOPHER transfers seem broken
|
2002-03-19 10:56:13 -05:00
|
|
|
|
2002-09-09 03:07:13 -04:00
|
|
|
* configure --disable-http is not fully supported. All other protocols seem
|
|
|
|
|
to work to disable.
|
|
|
|
|
|
2002-08-22 15:03:54 -04:00
|
|
|
* 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
|
