This sounds like a different problem than what I am seeing.

"Hang" was probably a bad description of my problem. curl doesn't actually
hang in my case, it just continues to loop over its read loop waiting for
something that is not going to happen. From an application perspective it
might appear to be hung, but it is not really deadlocked. Also I can get
this to occur without reusing handles so it is not related to connection
reuse in any way.

For my problem, I'm trying to look at RFC2616 to try and understand if the
server response is valid. Section 4.4 seems to be the relevant section,
but it is still not clear to me as to who is at fault, however the way I'm
reading it today has me leaning towards the server being the culprit since
of the 5 scenarios it defines:

1) Any response message which MUST NOT include a message body - Not the
case
2) If a Transfer-Encoding header field is present - Not the case
3) If a Content-Length header field is present - Not the case
4) If media type uses multipart/byteranges - Not the case
5) By the server closing the connection - It does not. I put a trace on
and the FIN doesn't come, the server leaves the connection open.

So at least in what I've found, this specific case does not seemed to be
spelled out unless it is somewhere understood that if none of the above
measures apply than the client should assume a content length of 0.

                                                                                                                               
                      Cyrill Osterwalder
                      <cyrill.osterwalder_at_seclution To: curl-library_at_lists.sourceforge.net
                      s.com> cc: co_at_seclutions.com
                      Sent by: Subject: Re: curl_easy_perform hangs on 7.9.8
                      curl-library-admin_at_lists.sour
                      ceforge.net
                                                                                                                               
                                                                                                                               
                      05/30/2003 04:32 AM
                      Please respond to
                      curl-library
                                                                                                                               
                                                                                                                               

I also experience curl_easy_perform of libcurl (7.10.3) hanging in the
select/poll every now and then but I do not know exactly yet for which kind
of requests/responses it happens. Apache server sits in read and waits and
libcurl sits in select/poll, both on the same socket. Deadlock. The Web
server works fine for other clients.

If I don't reuse the curl handle it does not seem to happen. However, I
cannot benefit from the SSL session resumes if I create the curl handle
from scratch every time. Reusing the curl handle seems to cause the trouble
even if FORBID_REUSE and FRESH_CONNECTION is set.

I'll investigate further and hope to give more details soon. Maybe some of
you can reproduce it already?

Regards,

Cyrill

--On Mittwoch, 28. Mai 2003 14:41 -0400 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?
>
> 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"
>
> My guess is that because the response header has no content-length (or
> specifiy chunked encoding) and has no data that the read loop which must
> get initialized to -1 does not know to quit until it timesout. However,
> the header does have "Connection: close" set, and I see that in the
header
> parsing curl sets a bit to signify this so perhaps the fix is to have the
> read loop check for this as well. (Or maybe just reset the expected
> length to 0 if we've parsed the whole header and not found a
> Content-Length)
>
> I'll try to pull the latest from CVS tomorrow and test it if necessary.
>
>
>
>
>
>
> -------------------------------------------------------
> 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-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-5
Received on 2003-05-30