From 3ef3f2b6f07f8ceeaa40bfd49a75902399615927 Mon Sep 17 00:00:00 2001
From: Daniel Stenberg <daniel@haxx.se>
Date: Wed, 21 Apr 2004 08:56:02 +0000
Subject: [PATCH] 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 c97faea69c..24e7398db6 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 3f88bbcb1b..04d4e53323 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)
======================
--
GitLab