On Wed, Sep 24, 2008 at 01:01:23PM -0700, I wrote:
> It seems that something very similar happened before this patch, but
> for one critical read the error was supressed. In that case, curl did
> detect the situation immediately afterward and retry the request, saying
> "Connection died, trying a fresh connect".

This is going to be tricky to solve. How can you tell the difference
between a race condition (between sending a new request and the remote server
closing the connection) and the server deliberately or accidentally
(but illegally) closing the connection AFTER and BECAUSE OF the request? In
the latter case, retrying the request will fail again and potentially
result in an infinite loop.

The following patch makes all my tests pass again, but it's only marginally
better than my last patch. It still has the potential of missing a
genuine error and retrying when it shouldn't. Maybe Curl_retry_request
should be changed to only attempt to retry a request once to avoid a
possible infinite loop.

diff -u -r1.411 transfer.c
--- lib/transfer.c 8 Sep 2008 19:34:58 -0000 1.411
+++ lib/transfer.c 24 Sep 2008 22:11:01 -0000
@@ -2465,10 +2465,11 @@
 
       if(res == CURLE_OK) {
         res = Transfer(conn); /* now fetch that URL please */
- if(res == CURLE_OK) {
+ if((res == CURLE_OK) || (res == CURLE_RECV_ERROR)) {
           bool retry = Curl_retry_request(conn, &newurl);
 
           if(retry) {
+ res = CURLE_OK;
             follow = FOLLOW_RETRY;
             if (!newurl)
               res = CURLE_OUT_OF_MEMORY;

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved