- Jan 04, 2007
-
-
Daniel Stenberg authored
function(s) using SessionHandle pointers
-
- Dec 11, 2006
-
-
Daniel Stenberg authored
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.
-
- Nov 25, 2006
-
-
Daniel Stenberg authored
-
Daniel Stenberg authored
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.
-
- Nov 20, 2006
-
-
Yang Tse authored
This is done to back out changes done in revisions 1.77 and 1.75
-
Yang Tse authored
This is done to back out changes done from revisions 1.213 to 1.217
-
Yang Tse authored
This is done to back out changes done from revisions 1.6 to 1.10
-
Yang Tse authored
-
Yang Tse authored
-
Yang Tse authored
have proper TERM and INT signal handlers implemented.
-
- Nov 19, 2006
-
-
Daniel Stenberg authored
-
Yang Tse authored
servers hash, and adjust message arguments accordingly.
-
Yang Tse authored
be clear of warnings. Uncomment it if this module is further modified. The "warnings" module requires perl 5.006 or later. Previous perl versions don't have it and die on missing modules.
-
- Nov 18, 2006
- Nov 17, 2006
-
-
Yang Tse authored
server holds not only its two main pids, but also the pidfile of the test server and the 'slavepidfiles' for ftp* servers. This allows a better control when stopping servers. Now from runtests.pl when test servers are stopped they are signalled in sequence TERM, INT and KILL allowing time in between for them to die. This will give us a chance of gracefully stopping test servers, which we didn't have when we were killing them in first instance.
-
- Nov 13, 2006
-
-
Daniel Stenberg authored
-
- Nov 09, 2006
-
-
Yang Tse authored
Add failure checking for servers when fork()ed. Use same code path in 'stopserver' when called with a single or multiple pids.
-
- Nov 03, 2006
- Nov 02, 2006
- Nov 01, 2006
-
-
Yang Tse authored
when more than FD_SETSIZE file descriptors are open. This means that if for any reason we are not able to open more than FD_SETSIZE file descriptors then test 518 should not be run. test 537 is all about testing libcurl functionality when the system has nearly exhausted the number of free file descriptors. Test 537 will try to run with very few free file descriptors.
-
- Oct 31, 2006
- Oct 30, 2006
-
-
Yang Tse authored
preventing execution of this test on many platforms
-
- Oct 29, 2006
-
-
Yang Tse authored
-
- Oct 27, 2006
-
-
Daniel Stenberg authored
-
Yang Tse authored
-
Yang Tse authored
-
- Oct 26, 2006
-
-
Gisle Vanem authored
on Win32.
-
Yang Tse authored
- Take in account RLIM_INFINITY. - Verify that soft limit is actually changed when doing so. - Show errno in case getrlimit or setrlimit fails. - Keep file descriptors open only while runing this test.
-
Yang Tse authored
-
- Oct 25, 2006
-
-
Daniel Stenberg authored
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.
-