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!

  during certain conditions. I also changed this code to use realloc() based
  on Daniel Fandrich's suggestion.

new date strings to get tested too.

706 and 707.

  file for libcurl, and while doing that fix he unified with curl-config.in
  how the supported protocols and features are extracted and used, so both those
  tools should now always be synced.

pre 7.19.0 libcurl-using apps

165 - "Problem with CURLOPT_RESUME_FROM and CURLOPT_APPEND" by Daniele Pinau,
      recipe: http://curl.haxx.se/mail/lib-2008-08/0439.html

to HTTP 1.0 upon receiving a response from the HTTP server.  Tests 1072
and 1073 are similar to test 1069 in that they involve the impossible
scenario of sending chunked data to a HTTP 1.0 server.  All these currently
fail and are added to DISABLED.

Added test 1075 to test --anyauth with Basic authentication.

  "Connection: close" and actually close the connection after the
  response-body, libcurl could still have outstanding data to send and it
  would not properly notice this and stop sending. This caused weirdness and
  sad faces. http://curl.haxx.se/bug/view.cgi?id=2080222

  Note that there are still reasons to consider libcurl's behavior when
  getting a >= 400 response code while sending data, as Craig Perras' note
  "http upload: how to stop on error" specifies:
  http://curl.haxx.se/mail/archive-2008-08/0138.html