When an easy handle is used to download an URI which has no
Content-Length header (or equivalent) after downloading an URI which
does, the value from the previous transfer is reused and returned by
CURLINFO_CONTENT_LENGTH_DOWNLOAD. This is because the progress flags
(used to determine whether such a header was received) are not reset
between transfers.
Bug: http://curl.haxx.se/bug/view.cgi?id=3370895
When libcurl has said to the server that there's a POST or PUT coming
(with a content-length and all) it has to either deliver that amount of
data or it needs to close the connection before trying a second request.
Adds test case 1129, 1130 and 1131
The bug report is about when used with 100-continue, but the change is
more generic.
Bug: http://curl.haxx.se/mail/lib-2011-06/0191.html
Reported by: Steven Parkes
"test -e" is POSIX but clearly was not supported by the SunOS sh
version, -f is supported and should be a decent equivalent
Bug: http://curl.haxx.se/bug/view.cgi?id=3371574
gssapi.h is used as a header name by Heimdal-style GSSAPI so it would
conflict with a private header using that name, and while renaming the
header I figured we should name the .c file accordingly as well.
Bug: http://curl.haxx.se/mail/lib-2011-07/0071.html
Reported by: Ben Greear
Modern gcc versions (4.6.X) get more picky by default and have started
to warn for unused parameters, but luckily gcc also allows us to mark
them as unused so that we can avoid the warnings.
First, the -J/--remote-header-name was wrongly sorted in the --help
output as pointed out in bug report #3349271.
Then, I changed the format of the texts to follow the man page better in
that it now uses "-A, --long" intead of "-A/--long". I also made all
additional arguments get written as in "-A, --long FILENAME" instead of
the previous "<filename>" style.
Reported by: Herve Amblard
Bug: http://curl.haxx.se/bug/view.cgi?id=3349271
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.
Yang Tse