| Age | Commit message (Collapse) | Author |
|---|
|
at https://bugzilla.redhat.com/show_bug.cgi?id=453612#c12
If an incorrect password is given while loading a private key, libcurl ends
up in an infinite loop consuming memory. The bug is critical.
|
|
as reported by Ebenezer Ikonne (on curl-users) and Laurent Rabret (on
curl-library). The transfer was mistakenly marked to get more data to send
but since it didn't actually have that, it just hung there...
|
|
KEEP_RECV to better match the general terminology: receive and send is what we
do from the (remote) servers. We read and write from and to the local fs.
|
|
byte in the digest code.
|
|
|
|
|
|
'connected' truly is false when the socks connect fails.
Curl_done() fixed for the check-conn->bits.done-before-Curl_getoff_all_pipelines case
|
|
|
|
|
|
|
|
for conversion to later VS versions.
|
|
for conversion to later VS versions.
|
|
(http://curl.haxx.se/bug/view.cgi?id=2784055) identifying a problem to
connect to SOCKS proxies when using the multi interface. It turned out to
almost not work at all previously. We need to wait for the TCP connect to
be properly verified before doing the SOCKS magic.
There's still a flaw in the FTP code for this.
|
|
|
|
well. See change 28 Apr 2009.
|
|
committed May 4.
Additionally some identation fixes.
|
|
(http://curl.haxx.se/bug/view.cgi?id=2723236) identifying a problem with
libcurl's TFTP code and its lack of dealing with the OACK packet.
|
|
|
|
one and store the current one, as it makes the code less complex and I'm not
even sure I can check for the same session id using memcmp() like that.
|
|
corresponding fix in the GnuTLS code: make sure to store the new session id
in case the re-used one is rejected.
|
|
(http://curl.haxx.se/bug/view.cgi?id=2786255) with a patch, identifying how
libcurl did not deal with SSL session ids properly if the server rejected a
re-use of one. Starting now, it will forget the rejected one and remember
the new. This change was for OpenSSL only, it is likely that other SSL lib
code needs similar fixes.
|
|
platform HTTP requests" patch
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I've now made TFTP "connections" not being kept for re-use within libcurl.
TFTP is UDP-based so the benefit was really low (if even existing) to begin
with so instead of tracking down to fix this problem we instead removed the
re-use. I also enabled test case 1099 that I wrote a few days ago to verify
that this change fixes the reported problem.
|
|
(http://curl.haxx.se/bug/view.cgi?id=2783090) pointing out that on windows
we need to grow the SO_SNDBUF buffer somewhat to get really good upload
speeds. http://support.microsoft.com/kb/823764 has the details. Friends
confirmed that simply adding 32 to CURL_MAX_WRITE_SIZE is enough.
|
|
|
|
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!
|
|
|
|
Wegener pointed out that CURLINFO_APPCONNECT_TIME didn't work with the multi
interface and provided a patch that fixed the problem!
|
|
Previous workaround proved useful, and finally did not trigger any warning!
|
|
|
|
workaround.
Previous workaround proved useful, but triggered the following warning:
warning #556: a value of type "volatile Curl_addrinfo *" cannot be assigned to an entity of type "Curl_addrinfo *"
|
|
workaround.
The #pragma optimize("", off) attempt did not fix the problem and SIGSEGV's in Curl_freeaddrinfo() were back.
|
|
|
|
9.1 on unix IA32.
Previous 'volatile' variables workaround proved useful, but it triggered the following warning:
warning #167: argument of type "volatile Curl_addrinfo *" is incompatible with parameter of type "void *"
|
|
|
|
setup_once.h. Inclusion of each header file is based on the definition of
NEED_MALLOC_H and NEED_MEMORY_H respectively.
|
|
|
|
how it occurs (http://curl.haxx.se/mail/lib-2009-04/0289.html). The
conclusion was that if an error is detected and Curl_done() is called for
the connection, ftp_done() could at times return another error code that
then would take precedence and that new code confused existing logic that
works for the first error code (CURLE_SEND_ERROR) only.
|
|
|
|
|
|
|
|
proxy. libcurl would then wrongly close the connection after each
request. In his case it had the weird side-effect that it killed NTLM auth
for the proxy causing an inifinite loop!
I added test case 1098 to verify this fix. The test case does however not
properly verify that the transfers are done persistently - as I couldn't
think of a clever way to achieve it right now - but you need to read the
stderr output after a test run to see that it truly did the right thing.
|
|
|
