transfers. They are done on non-windows systems and translate CRLF to LF.

the stream (wrongly) lacks a proper zlib header. This seems to be the case on
too many actual server implementations.

the control connection when using FTP, for example when you remove an easy
handle from a multi stack.

typecast in the curl tool leading to a crash with (64bit?) VS2005 (at least)
since the struct timeval field tv_sec is an int while time_t is 64bit.

(http://curl.haxx.se/mail/lib-2006-02/0154.html) by adding the NTLM hash
function in addition to the LM one and making some other adjustments in the
order the different parts of the data block are sent in the Type-2 reply.
Inspiration for this work was taken from the Firefox NTLM implementation.

I edited the existing 21(!) NTLM test cases to run fine with these news. Due
to the fact that we now properly include the host name in the Type-2 message
the test cases now only compare parts of that chunk.

occurred when asking libcurl to follow HTTP redirects and the original URL had
more than one question mark (?). Added test case 276 to verify.

--enable-debug, as then curl used free() on memory allocated both with
normal malloc() and with libcurl-provided functions, when the latter MUST be
freed with curl_free() in debug builds.

called bind() with a too big argument in the 3rd parameter and at least
Tru64, AIX and IRIX seem to be very picky about it.

(when using OpenSSL).

reacts properly according to the CURLOPT_FTP_SSL setting.

with the multi interface and multi-part formposts. The fix from February
22nd could make the Curl_done() function get called twice on the same
connection and it was not designed for that and thus tried to call free() on
an already freed memory area!

is used properly.

callback" error message so I've now made the setting of that callback not be
as critical as before. The function is only used for additional loggging/
trace anyway so a failure just means slightly less data. It should still be
able to proceed and connect fine to the server.

(http://curl.haxx.se/bug/view.cgi?id=1431750) helped me identify and fix two
different but related bugs:

1) Removing an easy handle from a multi handle before the transfer is done
   could leave a connection in the connection cache for that handle that is
   in a state that isn't suitable for re-use. A subsequent re-use could then
   read from a NULL pointer and segfault.

2) When an easy handle was removed from the multi handle, there could be an
   outstanding c-ares DNS name resolve request. When the response arrived,
   it caused havoc since the connection struct it "belonged" to could've
   been freed already.

Now Curl_done() is called when an easy handle is removed from a multi handle
pre-maturely (that is, before the transfer was complteted). Curl_done() also
makes sure to cancel all (if any) outstanding c-ares requests.

type to the already provided type CURLPROXY_SOCKS4.
I added a --socks4 option that works like the current --socks5 option but
instead use the socks4 protocol.

content when libcurl didn't honor the internal ignorebody flag.

code. It should however not be the cause of any troubles. He also fixed a
few similar problems in the HTTP test server code.

as previously it could be holding on to old cached entries longer than
requested.

an app can use to let libcurl only connect to a remote host and then extract
the socket from libcurl. libcurl will then not attempt to do any transfer at
all after the connect is done.

instead of LDFLAGS.

with re-used FTP connections. If the second request on the same connection was
set not to fetch a "body", libcurl could get confused and consider it an
attempt to use a dead connection and would go acting mighty strange.

curl tool with --local-port. Plain and simply set the range of ports to bind
the local end of connections to. Implemented on to popular demand.

Not extensively tested. Please let me know how it works.

connection setup as a follow-redirect. It turns out 1) this fails when a FTP
connection is re-setup and 2) it does make the max-redirs counter behave
wrong. This fix was not verified since the reporter vanished, but I believe
this is the right fix nonetheless.

even after EPSV returned a positive response code, if libcurl failed to
connect to the port number the EPSV response said. Obviously some people are
going through protocol-sensitive firewalls (or similar) that don't understand
EPSV and then they don't allow the second connection unless PASV was
used. This also called for a minor fix of test case 238.