CURLM_CALL_MULTI_PERFORM stopped being a valid return code from
curl_multi_perform back in 7.20.0. All the libcurl tests are ajusted to
this and no longer check for this return code. Makes them simpler.
Autobuild submitters can use this to add some text to their
setup files to describe issues they've found with the build
or tests. This could include laying blame on test failures on
network issues or dependent libraries, explaining away compiler
warnings or providing any additional information that could be
useful to people reviewing and investigating problems with the
publicly available autobuild logs. Note that persistent test
failures that are not issues with curl itself should normally be
fixed by excluding them from the test run instead.
This is an entirely optional field that is not entered by the
user the first time a new build is created.
adding unit test for Curl_llist_move, documenting unit-tested functions
in llist.c, changing unit-test to unittest, replacing assert calls with
abort_unless calls
The CURLFORM_STREAM is documented to only insert a file name (and thus
look like a file upload) in the part if CURLFORM_FILENAME is set, but in
reality it always inserted a filename="" and if CURLFORM_FILENAME wasn't
set, it would insert insert rubbish (or possibly crash).
This is now fixed to work as documented, and test 554 has been extended
to verify this.
Reported by: Sascha Swiercy
Bug: http://curl.haxx.se/mail/lib-2011-06/0070.html
Properly deal with the fact that the last fread() call most probably is
a short read, and when using callbacks in fact all calls can be short
reads. No longer consider a file read done until it returns a 0 from the
read function.
Reported by: Aaron Orenstein
Bug: http://curl.haxx.se/mail/lib-2011-06/0048.html
If a piece is set to use a callback to get the data, it should not be
treated as data. It unfortunately also requires that curl_easy_perform()
or similar has been used as otherwise the callback function hasn't been
figured out and curl_formget won't know how to get the content.
When closing a connection, the speedchecker's timestamp is now deleted
so that it cannot accidentally be used by a fresh connection on the same
handle when examining the transfer speed.
Bug: https://bugzilla.redhat.com/679709
When a time condition isn't met, so that no body is delivered to the
application even though a 2xx response is being read from the server, we
must close the connection to avoid a re-use of the connection to be
completely tricked.
Added test 1128 to verify.
