release, or bump or whatevere

the function we should use, while both curl_multi_socket() and
curl_multi_socket_all() should be killed!

not in the mood enough to fight this now.

65. When doing FTP over a socks proxy or CONNECT through HTTP proxy and the
  multi interface is used, libcurl will fail if the (passive) TCP connection
  for the data transfer isn't more or less instant as the code does not
  properly wait for the connect to be confirmed. See test case 564 for a first
  shot at a test case.

Renamed vc6 workspace and project files to avoid filename clash when used for conversion to later VS versions.

  reported in the Debian package.

report failed to mention that a proxy must be used to reproduce it.

  If the CURLOPT_PORT option is used on an FTP URL like
  "ftp://example.com/file;type=A" the ";type=A" is stripped off.

  I added test case 562 to verify, only to find out that I couldn't repeat
  this bug so I hereby consider it not a bug anymore!

  Chen pointed out how curl couldn't upload with resume when reading from a
  pipe.

  This ended up with the introduction of a new return code for the
  CURLOPT_SEEKFUNCTION callback that basically says that the seek failed but
  that libcurl may try to resolve the situation anyway. In our case this means
  libcurl will attempt to instead read that much data from the stream instead
  of seeking and that way curl can now upload with resume when data is read
  from a stream!

  Koenig pointed out that the man page didn't tell that the *_proxy
  environment variables can be specified lower case or UPPER CASE and the
  lower case takes precedence,

  for any further requests or transfers. The work-around is then to close that
  handle with curl_easy_cleanup() and create a new. Some more details:
  http://curl.haxx.se/mail/lib-2009-04/0300.html

"pointer to a char pointer".

  and 1 on fatal errors. Previously it only mentioned non-zero on fatal
  errors. This is a slight change in meaning, but it follows what we've done
  elsewhere before and it opens up for LOTS of more useful return codes
  whenever we can think of them...

functions if the easy handles are used in multiple threads

more issues for authors to consider when writing robust libcurl-using
applications.

  (http://curl.haxx.se/docs/adv_20090303.html also known as CVE-2009-0037) in
  which previous libcurl versions (by design) can be tricked to access an
  arbitrary local/different file instead of a remote one when
  CURLOPT_FOLLOWLOCATION is enabled. This flaw is now fixed in this release
  together this the addition of two new setopt options for controlling this
  new behavior:

  o CURLOPT_REDIR_PROTOCOLS controls what protocols libcurl is allowed to
  follow to when CURLOPT_FOLLOWLOCATION is enabled. By default, this option
  excludes the FILE and SCP protocols and thus you nee to explicitly allow
  them in your app if you really want that behavior.

  o CURLOPT_PROTOCOLS controls what protocol(s) libcurl is allowed to fetch
  using the primary URL option. This is useful if you want to allow a user or
  other outsiders control what URL to pass to libcurl and yet not allow all
  protocols libcurl may have been built to support.

  CURLINFO_CONTENT_LENGTH_DOWNLOAD and CURLINFO_CONTENT_LENGTH_UPLOAD return
  -1 if the sizes aren't know. Previously these returned 0, make it impossible
  to detect the difference between actually zero and unknown.

  to the proper 'libcurl' as clearly this caused confusion.