On Mon, 2 Jun 2003 RBramante_at_on.com wrote:

> I tend to agree with this analysis that this is a server bug more than a
> client bug (as mentioned, IE 6.0 behaves the same as curl under these
> conditions.) given my understanding of 2616 (the server this is happening
> against is tomcat).

Agreement.

> Actually, one of my test results was the same as yours: when I closed the
> connection on the server side curl did return from its poll as expected.
> What I tried to point out was that I think there is still a curl bug, and
> that is the case where the server sets "Content-Length: 0" in the header.
> In that case, curl again stayed in its read loop until timeout (IE 6.0
> exitied out in this case). Now, even though the server did not close the
> connection, shouldn't curl still've exited since it was given a
> Content-Length to use? Or is the server still obligated to close the
> connection since it set "Connection: close" in the header?

No, you are right. Setting the Content-Length to zero should stop libcurl
from waiting for the closure.

Can you check if this patch corrects this particular problem:

--- transfer.c 2 Jun 2003 13:14:57 -0000 1.154
+++ transfer.c 2 Jun 2003 14:00:39 -0000
@@ -457,7 +457,7 @@
                  */
                 if(data->set.no_body)
                   stop_reading = TRUE;
- else if(!conn->bits.close) {
+ else {
                   /* If this is not the last request before a close, we must
                      set the maximum download size to the size of the
                      expected document or else, we won't know when to stop

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5