curl-library
Re: curl_easy_perform hangs on 7.9.8
Date: Mon, 2 Jun 2003 09:47:04 -0400
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).
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?
Daniel Stenberg
<daniel_at_haxx.se> To: libcurl Mailing list <curl-library_at_lists.sourceforge.net>
Sent by: cc:
curl-library-admin_at_lists.sour Subject: Re: curl_easy_perform hangs on 7.9.8
ceforge.net
06/02/2003 08:59 AM
Please respond to
curl-library
On Wed, 28 May 2003 RBramante_at_on.com wrote:
> I just hit this weird condition with 7.9.8. I haven't tried it with the
> latest yet, and it's not clear to me if the problem is curl vs. with the
> server response header. Any thoughts?
I've read the other mails in this thread, I'm replying to your initial mail
though since I can quote better here. I was gone for a few days and
couldn't
reply sooner...
> Basically, I've started to hit a scenario where curl hangs until its IO
> timeout if the server responds with something like the following:
>
> HTTP/1.1 400 Bad Request
> Content-Type: text/html
> Date: Wed, 28 May 2003 18:37:02 GMT
> Connection: close
> Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector)
>
> eventually perform will return 28 "Operation timed out with 0 out of -1
> bytes received"
(In later mails you noted that this also happens using libcurl 7.10.5.)
In your original test, this didn't close the socket after this response? If
so, what did you expect libcurl to do? It says "Connection: close" and
there's no content-length, which to my understanding basicly means that the
client should keep on reading everything until the server closes the
connection. The client has no other means of knowing when the server has
sent
everything it wants to send. HTTP error code 400 is not forbidden to
include
a body-part (in fact RFC2616 says "the server SHOULD include an entity") so
we can't bluntly stop reading after the headers either.
I wrote up a quick test case that returned these headers as shown above,
and
then the server immediately closed the socket. Then curl stopped reading at
once and return back quite as expected. You mentioned a different test
result
when you close the socket immediately after this response. Can you provide
a
test setup for me?
I can commit my test case for this to CVS in case it'll help.
-- 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 ------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5Received on 2003-06-02