Age | Commit message (Collapse) | Author |
|
76 private header files renamed to use our standard naming scheme.
This change affects 322 files in libcurl's source tree.
|
|
Inclusion of top two most included header files now done in setup_once.h
|
|
The text "additional stuff not fine" text was added for debug purposes a
while ago, but it isn't really helping anyone and for some reason some
Linux distributions provide their libcurls built with debug info still
present and thus (far too many) users get to read this info.
|
|
As a handle can be re-used after having done HTTP auth in a previous
request, it must make sure to clear out the HTTP types that aren't
wanted in this new request.
|
|
This reverts commit ce8311c7e49eca93c136b58efa6763853541ec97.
The commit made test 2024 work but caused a regression with repeated
Digest authentication. We need to fix this differently.
|
|
The Curl_reconnect_request() function could end up returning a pointer
to a free()d struct when Curl_done() failed inside. Clearing the pointer
unconditionally after Curl_done() avoids this risk.
Reported by: Ho-chi Chen
Bug: http://curl.haxx.se/mail/lib-2012-09/0188.html
|
|
When figuring out if the data stream needs to be rewound when the
request is to be resent, we must not access the HTTP struct unless the
protocol used is indeed HTTP...
Bug: http://curl.haxx.se/bug/view.cgi?id=3544688
|
|
|
|
As it turns out, some people do want that after all.
|
|
With FOLLOWLOCATION enabled. When a 3xx page is downloaded and the
download size was known (like with a Content-Length header), but the
subsequent URL (transfered after the 3xx page) was chunked encoded, then
the previous "known download size" would linger and cause the progress
meter to get incorrect information, ie the former value would remain
being sent in. This could easily result in downloads that were WAY
larger than "expected" and would cause >100% outputs with the curl
command line tool.
Test case 599 was created and it was used to repeat the bug and then
verify the fix.
Bug: http://curl.haxx.se/bug/view.cgi?id=3510057
Reported by: Michael Wallner
|
|
|
|
|
|
The load host names to DNS cache function was moved to hostip.c and it
now makes sure to not add host names that already are present in the
cache. It would previously lead to memory leaks when for example using
the --resolve and multiple URLs on the command line.
|
|
The commit 9dd85bc unintentionally changed the way we compute the time
spent waiting for 100-continue. In particular, when using a SSL client
certificate, the time spent by SSL handshake was included and could
cause the CURL_TIMEOUT_EXPECT_100 timeout to be mistakenly fired up.
Bug: https://bugzilla.redhat.com/767490
Reported by: Mamoru Tasaka
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Just internal stuff...
Curl_safefree is now a macro defined in memdebug.h instead of a function
prototyped in url.h and implemented in url.c, so inclusion of url.h is no
longer required in order to simply use Curl_safefree.
Provide definition of macro WHILE_FALSE in setup_once.h in order to allow
other macros such as DEBUGF and DEBUGASSERT, and code using it, to compile
without 'conditional expression is constant' warnings.
The WHILE_FALSE stuff fixes 150+ MSVC compiler warnings.
|
|
|
|
|
|
First:
File curl_ntlm.h renamed curl_ntlm_msgs.h
File curl_ntlm.c renamed curl_ntlm_msgs.c
Afterwards:
File http_ntlm.c renamed curl_ntlm.c
File http_ntlm.h renamed curl_ntlm.h
|
|
Curl_readrewind() was called without checking its return code, which
could lead to badness.
Bug: http://curl.haxx.se/bug/view.cgi?id=3349227
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
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.
|
|
It was mostly typecasted to int all over the code so switching to long
instead all over should be a net gain.
|
|
Introduced the initial setup to allow closesocket callbacks by making
sure sclose() is only ever called from one place in the libcurl source
and still run all test cases fine.
|
|
|
|
Made several functions static
Made one function defined to nothing when RTSP is disabled to avoid
the #ifdefs in code.
Removed explicit rtsp.h includes
|
|
Add a 'readwrite' function to the protocol handler struct and use that
for the extra readwrite functionality RTSP needs.
|
|
|
|
"if(a)" is our style, not "if( a )"
|
|
By the use of a the new lib/checksrc.pl script that checks that our
basic source style rules are followed.
|
|
asyn-ares.c and asyn-thread.c are two separate backends that implement
the same (internal) async resolver API for libcurl to use. Backend is
specified at build time.
The internal resolver API is defined in asyn.h for asynch resolvers.
|
|
Found with codespell.
|
|
|
|
Made it compile and work again after the code move.
|
|
Massively reduce #ifdefs all over (23 #ifdef lines less so far)
Moved conversion-specific code to non-ascii.c
|
|
Since this struct member is used in the code to determine what and how
to decode automatically and since it is now also used for compressed
Transfer-Encodings, I renamed it to the more suitable 'auto_decoding'
|
|
Also add test case 584 for the same
Bug: http://curl.haxx.se/bug/view.cgi?id=3214223
|
|
|
|
Curl_posttransfer is called too soon to add the final new line.
Moved the new line logic to pgrsDone as there is no more call to
update the progress status after this call.
Reported by: Dmitri Shubin <sbn_at_tbricks.com>
http://curl.haxx.se/mail/lib-2010-12/0162.html
|
|
When libcurl sends a HTTP request on a re-used connection and detects it
being closed (ie no data at all was read from it), it is important to
rewind if any data in the request was sent using the read callback or
was read from file, as otherwise the retried request will be broken.
Reported by: Chris Smowton
Bug: http://curl.haxx.se/bug/view.cgi?id=3195205
|