From 3ef3f2b6f07f8ceeaa40bfd49a75902399615927 Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Wed, 21 Apr 2004 08:56:02 +0000 Subject: test case 160 "should work" now --- CHANGES | 12 ++++++++++++ TODO-RELEASE | 15 +-------------- 2 files changed, 13 insertions(+), 14 deletions(-) diff --git a/CHANGES b/CHANGES index c97faea69..24e7398db 100644 --- a/CHANGES +++ b/CHANGES @@ -6,6 +6,18 @@ Changelog +Daniel (21 April 2004) +- Modified the heuristics for dealing with the test 160 scenario. When a + connection is re-used and nothing at all is received from it (because the + server closes the connection), we will now retry the request on a fresh new + connection. The previous ECONNRESET stuff from January 30 was removed again + as it didn't detect the situation good enough. + +Daniel (20 April 2004) +- Added test case 160 to verify that curl works correctly when it gets a + connection reset when trying to re-use a connection. It should then simply + create a new connection and resend the request. + Daniel (19 April 2004) - No more 512 byte limit for host name (inclusing name + password) in libcurl. An added bonus is that we use less memory for the typical (shorter URL) diff --git a/TODO-RELEASE b/TODO-RELEASE index 3f88bbcb1..04d4e5332 100644 --- a/TODO-RELEASE +++ b/TODO-RELEASE @@ -3,22 +3,9 @@ Issues not sorted in any particular order. UNASSIGNED means that no person has publicly stated to work on the issue. DELETE means the issue is subject for dismissal -To get fixed in 7.11.2 (planned release late April/early May 2004) +To get fixed in 7.11.2 (planned release late April 2004) ====================== -36. autobuild test failures on Tru64/IRIX (test case 88 for example) - - The problem is once again (this is the same scenario we had before in the - notorious test case 91 failure bug hunt) that when doing a second request, - the client hasn't yet found out that the previous connection is on its way - to get closed. It then re-uses the connection only to find it closed right - away. - - We have code starting at lib/transfer.c:1949 that is supposed to detect - this situation and enforce a retry. This retry never happens on these - failures, indicating that the check is bad or that some code has ruined the - values used in the check. - To get fixed in 7.12.0 (no date) ====================== -- cgit v1.2.3