So, until fixed this will remain FIXME.

  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!

non-configured libcurl. In this case curl_off_t data type was gated
to the off_t data type which depends on the _FILE_OFFSET_BITS. This
configuration is exactly the unwanted configuration for our curl_off_t
data type which must not depend on such setting. This breaks ABI for
libcurl libraries built with Sun compilers which were built without
having run the configure script with _FILE_OFFSET_BITS different than
64 and using the ILP32 data model.

Initial CMake scripts (libcurl only), based on the merge of tetest scripts and mine. These are far to be functionnal yet.
PS: Hello world :)

  other libcurl function.

  (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.

  plain FTP connections, and it will then allow MKD to fail once and retry the
  CWD afterwards. This is especially useful if you're doing many simultanoes
  connections against the same server and they all have this option enabled,
  as then CWD may first fail but then another connection does MKD before this
  connection and thus MKD fails but trying CWD works! The numbers can
  (should?) now be set with the convenience enums now called
  CURLFTP_CREATE_DIR and CURLFTP_CREATE_DIR_RETRY.

  Tests has proven that if you're making an application that uploads a set of
  files to an ftp server, you will get a noticable gain in speed if you're
  using multiple connections and this option will be then be very useful.

  the condition in the previous request was unmet. This is typically a time
  condition set with CURLOPT_TIMECONDITION and was previously not possible to
  reliably figure out. From bug report #2565128
  (http://curl.haxx.se/bug/view.cgi?id=2565128)

  version 1.1 instead of 1.0 like before. This change also introduces the new
  proxy type for libcurl called 'CURLPROXY_HTTP_1_0' that then allows apps to
  switch (back) to CONNECT 1.0 requests. The curl tool also got a --proxy1.0
  option that works exactly like --proxy but sets CURLPROXY_HTTP_1_0.

  I updated all test cases cases that use CONNECT and I tried to do some using
  --proxy1.0 and some updated to do CONNECT 1.1 to get both versions run.

  CURLOPT_SOCKS5_GSSAPI_SERVICE and CURLOPT_SOCKS5_GSSAPI_NEC to allow libcurl
  to do GSS-style authentication with SOCKS5 proxies. The curl tool got the
  options called --socks5-gssapi-service and --socks5-gssapi-nec to enable
  these.

  to set desired block size to use for TFTP transfers instead of the default
  512 bytes.

  They basically offer the same thing the NO_PROXY environment variable only
  offered previously: list a set of host names that shall not use the proxy
  even if one is specified.

  32 bit and 64 bit.

  SunPro compilers.

  there are servers "out there" that relies on the client doing this broken
  Digest authentication. Apache even comes with an option to work with such
  broken clients.

  The difference is only for URLs that contain a query-part (a '?'-letter and
  text to the right of it).

  libcurl now supports this quirk, and you enable it by setting the
  CURLAUTH_DIGEST_IE bit in the bitmask you pass to the CURLOPT_HTTPAUTH or
  CURLOPT_PROXYAUTH options. They are thus individually controlled to server
  and proxy.

  make CURLOPT_PROXYUSERPWD sort of deprecated. The primary motive for adding
  these new options is that they have no problems with the colon separator
  that the CURLOPT_PROXYUSERPWD option does.

  curl_easy_setopt: CURLOPT_USERNAME and CURLOPT_PASSWORD that sort of
  deprecates the good old CURLOPT_USERPWD since they allow applications to set
  the user name and password independently and perhaps more importantly allow
  both to contain colon(s) which CURLOPT_USERPWD doesn't fully support.

  CURLOPT_POST301 (but adds a define for backwards compatibility for you who
  don't define CURL_NO_OLDIES). This option allows you to now also change the
  libcurl behavior for a HTTP response 302 after a POST to not use GET in the
  subsequent request (when CURLOPT_FOLLOWLOCATION is enabled). I edited the
  patch somewhat before commit. The curl tool got a matching --post302
  option. Test case 1076 was added to verify this.

  enabling this feature with CURLOPT_CERTINFO for a request using SSL (HTTPS
  or FTPS), libcurl will gather lots of server certificate info and that info
  can then get extracted by a client after the request has completed with
  curl_easy_getinfo()'s CURLINFO_CERTINFO option. Linus Nielsen Feltzing
  helped me test and smoothen out this feature.

  Unfortunately, this feature currently only works with libcurl built to use
  OpenSSL.

  This feature was sponsored by networking4all.com - thanks!