42. Daniel Black filed bug report #1705802 where he accurately mentions that
several FTP-SSL test cases fail when we build libcurl with NSS for TLS/SSL:
http://curl.haxx.se/bug/view.cgi?i

42. Daniel Black filed bug report #1705802 where he accurately mentions that
several FTP-SSL test cases fail when we build libcurl with NSS for TLS/SSL:
http://curl.haxx.se/bug/view.cgi?id=1705802

show more ...

blah

41. When doing an operation over FTP that requires the ACCT command (but not
when logging in), the operation will fail since libcurl does detect this and
thus fails to issue the correct c

41. When doing an operation over FTP that requires the ACCT command (but not
when logging in), the operation will fail since libcurl does detect this and
thus fails to issue the correct command:
http://curl.haxx.se/bug/view.cgi?id=1693337

show more ...

addressed (replied to with comments) most out-stading release issues and moved
one over to KNOWN_BUGS

Updated the test harness to check for protocol support before running each
test, fixing KNOWN_BUGS #11. Fixed some tests to more accurately specify
their required servers and features.

Works for me

New FTP CCC functionality - adds passive and active mode to accomodate for different server behaviour

- Robson Braga Araujo made passive FTP transfers work with SOCKS (both 4 and
5).

- Jeff Pohlmeyer identified two problems: first a rather obscure problem with
the multi interface and connection re-use that could make a
curl_multi_remove_handle() ruin a pointer in anot

- Jeff Pohlmeyer identified two problems: first a rather obscure problem with
the multi interface and connection re-use that could make a
curl_multi_remove_handle() ruin a pointer in another handle.

The second problem was less of an actual problem but more of minor quirk:
the re-using of connections wasn't properly checking if the connection was
marked for closure.

show more ...

Added --ftp-ssl-ccc issue.

- David McCreedy fixed the Curl command line tool for HTTP on non-ASCII
platforms.

- Victor Snezhko helped us fix bug report #1603712
(http://curl.haxx.se/bug/view.cgi?id=1603712) (known bug #36) --limit-rate
(CURLOPT_MAX_SEND_SPEED_LARGE and CURLOPT_MAX_RECV_SPEED_LARG

- Victor Snezhko helped us fix bug report #1603712
(http://curl.haxx.se/bug/view.cgi?id=1603712) (known bug #36) --limit-rate
(CURLOPT_MAX_SEND_SPEED_LARGE and CURLOPT_MAX_RECV_SPEED_LARGE) are broken
on Windows (since 7.16.0, but that's when they were introduced as previous
to that the limiting logic was made in the application only and not in the
library). It was actually also broken on select()-based systems (as apposed
to poll()) but we haven't had any such reports. We now use select(), Sleep()
or delay() properly to sleep a while without waiting for anything input or
output when the rate limiting is activated with the easy interface.

show more ...

37. Having more than one connection to the same host when doing NTLM
authentication (with performs multiple "passes" and authenticates a
connection rather than a HTTP request), and partic

37. Having more than one connection to the same host when doing NTLM
authentication (with performs multiple "passes" and authenticates a
connection rather than a HTTP request), and particularly when using the
multi interface, there's a risk that libcurl will re-use a wrong connection
when doing the different passes in the NTLM negotiation and thus fail to
negotiate (in seemingly mysterious ways).

36. --limit-rate (CURLOPT_MAX_SEND_SPEED_LARGE and
CURLOPT_MAX_RECV_SPEED_LARGE) are broken on Windows (since 7.16.0, but
that's when they were introduced as previous to that the limiting logic was
made in the application only and not in the library). This problem is easily
repeated and it takes a Windows person to fire up his/hers debugger in order
to fix. http://curl.haxx.se/bug/view.cgi?id=1603712

show more ...

Olaf Stueben provided a patch that I edited slightly. It fixes the notorious
KNOWN_BUGS #25, which happens when a proxy closes the connection when
libcurl has sent CONNECT, as part of an auth

Olaf Stueben provided a patch that I edited slightly. It fixes the notorious
KNOWN_BUGS #25, which happens when a proxy closes the connection when
libcurl has sent CONNECT, as part of an authentication negotiation. Starting
now, libcurl will re-connect accordingly and continue the authentication as
it should.

show more ...

the "work in progress" for #25 was ditched a long time ago

deleted #19 since it concerted FTP third party transfers and they are no longer
supported

corrected URL

so it seems SOCKS5 too (still) has problems with connect timeouts

- "Dortik" (http://curl.haxx.se/bug/view.cgi?id=1551412) provided a patch that
while not fixing things very nicely, it does make the SOCKS5 proxy
connection slightly better as it now ackn

- "Dortik" (http://curl.haxx.se/bug/view.cgi?id=1551412) provided a patch that
while not fixing things very nicely, it does make the SOCKS5 proxy
connection slightly better as it now acknowledges the timeout for connection
and it no longer segfaults in the case when SOCKS requires authentication
and you did not specify username:password.

show more ...

Peter Silva introduced CURLOPT_MAX_SEND_SPEED_LARGE and
CURLOPT_MAX_RECV_SPEED_LARGE that limit tha maximum rate libcurl is allowed
to send or receive data. This kind of adds the the command

Peter Silva introduced CURLOPT_MAX_SEND_SPEED_LARGE and
CURLOPT_MAX_RECV_SPEED_LARGE that limit tha maximum rate libcurl is allowed
to send or receive data. This kind of adds the the command line tool's
option --limit-rate to the library.

The rate limiting logic in the curl app is now removed and is instead
provided by libcurl itself. Transfer rate limiting will now also work for -d
and -F, which it didn't before.

show more ...

The SOCKS connection codes don't properly acknowledge (connect) timeouts.

Fixed known bug #28. The TFTP code no longer assumes a packed struct and
thus works reliably on more platforms.

David McCreedy brought line end conversions when doing FTP ASCII
transfers. They are done on non-windows systems and translate CRLF to LF.

33. Doing multi-pass HTTP authentication on a non-default port does not work.
This happens because the multi-pass code abuses the redirect following code
for doing multiple requests, and

33. Doing multi-pass HTTP authentication on a non-default port does not work.
This happens because the multi-pass code abuses the redirect following code
for doing multiple requests, and when we following redirects to an absolute
URL we must use the newly specified port and not the one specified in the
original URL. A proper fix to this would need to separate the negotiation
"redirect" from an actual redirect.

show more ...

fixed in CVS