| Age | Commit message (Collapse) | Author |
|---|
|
(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()
|
|
use gmtime_r
|
|
(http://curl.haxx.se/bug/view.cgi?id=1230118) curl_getdate() did not work
properly for all input dates on Windows. It was mostly seen on some TZ time
zones using DST. Luckily, Martin also provided a fix.
|
|
(http://curl.haxx.se/bug/view.cgi?id=1600447) in which he noted that active
FTP connections don't work with the multi interface. The problem is here that
the multi interface state machine has a state during which it can wait for the
data connection to connect, but the active connection is not done in the same
step in the sequence as the passive one is so it doesn't quite work for
active. The active FTP code still use a blocking function to allow the remote
server to connect.
The fix (work-around is a better word) for this problem is to set the
boolean prematurely that the data connection is completed, so that the "wait
for connect" phase ends at once.
|
|
HTTP upload was disconnected:
"What appears to be happening is that my system (Linux 2.6.17 and 2.6.13) is
setting *only* POLLHUP on poll() when the conditions in my previous mail
occur. As you can see, select.c:Curl_select() does not check for POLLHUP. So
basically what was happening, is poll() was returning immediately (with
POLLHUP set), but when Curl_select() looked at the bits, neither POLLERR or
POLLOUT was set. This still caused Curl_readwrite() to be called, which
quickly returned. Then the transfer() loop kept continuing at full speed
forever."
|
|
header in a third, not suppported by libcurl, format and we agreed that we
could make the parser more forgiving to accept all the three found
variations.
|
|
holding the conn->data value
|
|
responded with a single status line and no headers nor body. Starting now, a
HTTP response on a persistent connection (i.e not set to be closed after the
response has been taken care of) must have Content-Length or chunked
encoding set, or libcurl will simply assume that there is no body.
To my horror I learned that we had no less than 57(!) test cases that did bad
HTTP responses like this, and even the test http server (sws) responded badly
when queried by the test system if it is the test system. So although the
actual fix for the problem was tiny, going through all the newly failing test
cases got really painful and boring.
|
|
|
|
|
|
|
|
as appropriate for platforms that don't have autotools support
|
|
defining HAVE_SIGNAL_H if the header is available.
Added a check in configure that tests if the sig_atomic_t type is
available, defining HAVE_SIG_ATOMIC_T if it is available. Providing
a suitable default in setup_once.h if not available.
Added a check in configure that tests if the sig_atomic_t type is
already defined as volatile, defining HAVE_SIG_ATOMIC_T_VOLATILE
if it is available and already defined as volatile.
|
|
libssh2 startup.
|
|
|
|
|
|
|
|
They all now return ssize_t to Curl_write().
Unfortunately, Curl_read() is in a sorrier state but it too would benefit from
a similar cleanup.
|
|
Versions, not to ./Versions and indentation improvments
|
|
2006. It turned out we wrongly assumed that the connection cache was present
when tearing down a connection.
|
|
multi interface, but I could also repeat it doing multiple sequential ones
with the easy interface. Using Ciprian's test case, I could fix it.
|
|
CURLOPT_VERBOSE set to non-zero, you still got a few debug messages from the
SSL handshake. This is now stopped.
|
|
wrong error message in the error message buffer.
|
|
|
|
|
|
|
|
This was possible on debug c-ares enabled builds when both CURL_MEMDEBUG
and CARES_MEMDEBUG environment variables were set. Leading to a file handle
leak even when both variables had the same value, and wierd test suite
results when different.
|
|
|
|
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.
|
|
a fatal bug so we must require 1.3.2 to get flawless functionality with c-ares.
|
|
|
|
|
|
|
|
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.
|
|
|
|
and send(). Added needed HAVE_x defines.
|
|
|
|
|
|
|
|
to avoid picky compiler warnings, since this is what we want!
|
|
buffer used to store headers in the SessionHandle failed.
|
|
case when 401 or 407 are returned, *IF* no auth credentials have been given.
The CURLOPT_FAILONERROR option is not possible to make fool-proof for 401
and 407 cases when auth credentials is given, but we've now covered this
somewhat more.
You might get some amounts of headers transferred before this situation is
detected, like for when a "100-continue" is received as a response to a
POST/PUT and a 401 or 407 is received immediately afterwards.
Added test 281 to verify this change.
|
|
|
|
|
|
applies for asynch name resolves in general and not only ares
|
