On Mon, 26 Jan 2004, Patrick Smith wrote:

> [I first sent this on Sunday, but it hasn't appeared on the list yet, so
> here it is again. Apologies if it does appear twice.]

Many people have been struck by these problems, the sourceforge staff claims
they're now fixed...

> Test case 91 fails on my Linux system, using curl 7.11.0.

Yes, this is a known problem and I'll start right now by thanking you for
taking the time and effort to help us solve this.

(Let me also point out that there's a test case 96 in CVS that is similar to
this, but I change some stuff on it from time to time to see if the automatic
testing machines still fail on it.)

> However, when the test fails, libcurl seems to be re-using the original
> connection ("Re-using existing connection! (#0)" appears in thr stderr log).
> The server closes this connection without looking for more data, so libcurl
> gets an empty reply.
>
> I think the race is between the server's call to close() and libcurl's call
> to select() in SocketIsDead in lib/url.c. If the select happens first,
> libcurl will reuse the connection, and the test fails.

Hm, assuming that this is correct, which is likely and indeed something that
can happen this is what is *supposed* to be happening:

Curl_connect() succeeds. It (wrongly) thinks the connection is still alive to
be used. It then proceeds to call Curl_do() to issue the request for this
single "document".

Curl_do() calls the protocol-specific "do"-function, which in the case of HTTP
is called Curl_http(). That function is supposed to return CURLE_SEND_ERROR if
there's something wrong in the request sending. If the connection really just
was closed, curl should have problems sending the request and thus this is
what should happen.

I suspect that perhaps this isn't really happening.

Anyway, if Curl_http() returns CURLE_SEND_ERROR and the connection was
re-used, the connection will be closed "by force" and a new connection will be
made to the server and Curl_http() will be called again to attempt to send the
request on the new connection instead. If this *also* fails, a return code is
returned.

> I'd suggest that this race could occur in real life, whenever libcurl
> considers reusing a connection at about the same time as the server closes
> the connection. So libcurl should probably try to detect this case and open
> a new connection. (I'd guess the things to look for would be no data from
> the first recv() or the appropriate error (ECONNRESET?) from the first
> send()).

There is an attempt to detect and work-around this, I guess it just isn't
working properly.

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn