On Wed, 21 Apr 2004, Daniel Stenberg wrote:

(Talking to myself again)

> 5 - when curl sends its request, the server has or will close the connection
> (described in step 3)
> 6 - this situation is meant to be detected at lib/transfer.c:1949 and then
> libcurl should setup a new connection and retry the request on that.
>
> When test case 160 fails, as it currently does on Solaris, AIX, IRIX and
> Tru64 (at least) libcurl fails step 6. It only seems to work correctly on
> Linux atm.

The reason for this confusion is simple:

When the server has served the first request and simply hasn't closed the
first connection yet, curl sends away its second request fine.

If the server hasn't yet closed the socket:

  curl then reads 0 bytes from the socket, and returns CURLE_GOT_NOTHING

If the server has closed the socket:

  curl reads -1 and sees a ECONNRESET, which then allows for a retried
  request.

I now see quite clearly that the current "ECONNRESET hueristics" is crap. I
will instead move it over to a more generic check that might make libcurl
retry slightly more often:

If libcurl is re-using a connection and it receives nothing, it will retry on
a fresh new connect. If the problem with the server persists, it will end up
returning an error anyway. The "lingering close" will then not cause a
problem anymore.

Commit is pending.

-- 
     Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
      Dedicated custom curl help for hire: http://haxx.se/curl.html