| Age | Commit message (Collapse) | Author |
|---|
|
something went wrong like it got a bad response code back from the server,
libcurl would leak memory. Added test case 538 to verify the fix.
I also noted that the connection would get cached in that case, which
doesn't make sense since it cannot be re-use when the authentication has
failed. I fixed that issue too at the same time, and also that the path
would be "remembered" in vain for cases where the connection was about to
get closed.
|
|
|
|
(http://curl.haxx.se/bug/view.cgi?id=1604956) which identified setting
CURLOPT_MAXCONNECTS to zero caused libcurl to SIGSEGV. Starting now, libcurl
will always internally use no less than 1 entry in the connection cache.
|
|
Curl_done()
|
|
|
|
|
|
2006. It turned out we wrongly assumed that the connection cache was present
when tearing down a connection.
|
|
wrong error message in the error message buffer.
|
|
|
|
KNOWN_BUGS #25, which happens when a proxy closes the connection when
libcurl has sent CONNECT, as part of an authentication negotiation. Starting
now, libcurl will re-connect accordingly and continue the authentication as
it should.
|
|
|
|
compiler warning fix since it was Ok and actually
avoids the targeted compiler warning.
|
|
Assigning the const value zero to a pointer to function
results in a null pointer value assignment to the function
pointer.
Assignment of any nonzero value is what should result in a
implementation compiler dependent result.
Since what we want to do here is the first case, this should
not trigger compiler warnings related with conversions from
'pointer to data' to 'pointer to function'.
Our autobuild test suite will judge.
|
|
to avoid picky compiler warnings, since this is what we want!
|
|
buffer used to store headers in the SessionHandle failed.
|
|
|
|
applies for asynch name resolves in general and not only ares
|
|
re-use connections (for pipelining) before the name resolving is done.
|
|
(when the resoling isn't completede yet) and not confuse it with a simple
connection re-use (non-pipelined).
|
|
|
|
resolving is completed so we must make sure to survive it and mark the
connection as async (ie not yet connected completely).
|
|
ever actually are used
|
|
|
|
could very well cause a negate number get passed in and thus cause reading
outside of the array usually used for this purpose.
We avoid this by using the uppercase macro versions introduced just now that
does some extra crazy typecasts to avoid byte codes > 127 to cause negative
int values.
|
|
|
|
|
|
|
|
|
|
|
|
case 535 and it now runs fine. Again a problem with the pipelining code not
taking all possible (error) conditions into account.
|
|
|
|
would crash if a bad function sequence was used when shutting down after
using the multi interface (i.e using easy_cleanup after multi_cleanup) so
precautions have been added to make sure it doesn't any more - test case 529
was added to verify.
|
|
|
|
it now will read the full data sent from servers. The SOCKS-related code was
also moved to the new lib/socks.c source file.
|
|
empty password or no password at all. Test case 278 and 279 were added to
verify.
|
|
it basically was that we didn't remove the current connection from the pipe
list when following a redirect. Also in this commit: several cases of
additional debug code for debug builds helping to check and track down some
signs of run-time trouble.
|
|
currently fits in the cache, to make the cache work better especially for
pipelining cases but also for "mere" (persistent) connection re-use.
|
|
Curl_signalPipeClose is now signalPipeClose().
|
|
|
|
|
|
we certainly MUST NOT kill an active connection... Problem tracked down thanks
to Michael Wallner's excellent test program.
|
|
handle that is part of a multi handle first removes the handle from the
stack.
- Added CURLOPT_SSL_SESSIONID_CACHE and --no-sessionid to disable SSL
session-ID re-use on demand since there obviously are broken servers out
there that misbehave with session-IDs used.
|
|
|
|
|
|
|
|
problem with it (SIGSEGV-style). It clearly showed that the existing
socket-state and state-difference function wasn't good enough so I rewrote
it and could then re-run Jeff's program without any crash. The previous
version clearly could miss to tell the application when a handle changed
from using one socket to using another.
While I was at it (as I could use this as a means to track this problem
down), I've now added a 'magic' number to the easy handle struct that is
inited at curl_easy_init() time and cleared at curl_easy_cleanup() time that
we can use internally to detect that an easy handle seems to be fine, or at
least not closed or freed (freeing in debug builds fill the area with 0x13
bytes but in normal builds we can of course not assume any particular data
in the freed areas).
|
|
|
|
|
|
|
|
cache within the multi handle.
|
