something beyond ascii but currently libcurl will only pass in the verbatim
  string the app provides. There are several browsers that already do this
  encoding. The key seems to be the updated draft to RFC2231:
  http://tools.ietf.org/html/draft-reschke-rfc2231-in-http-02

  They introduce known_host support for SSH keys to libcurl. See docs for
  details.

  http://curl.haxx.se/bug/view.cgi?id=2818950

  errno is not reset on success.

updated openssl version to latest; removed obsolete link to openssl patch since its now in the openssl releases.

renamed generated config.h to curl_config.h in order to avoid clashes when libcurl is used with other projects which also have a config.h.

  range if given colon-separated after the host name/address part. Like
  "192.168.0.1:2000-10000"

pointed out!

With the curl memory tracking feature decoupled from the debug build feature,
CURLDEBUG and DEBUGBUILD preprocessor symbol definitions are used as follows:

CURLDEBUG used for curl debug memory tracking specific code (--enable-curldebug)

DEBUGBUILD used for debug enabled specific code (--enable-debug)

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!