Ok, I see the differences but I still think we might be looking at the same
problem.

>"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.

That's exactly the same behaviour I observe. Curl loops over its polling
read loop on the socket but there are no bytes coming from the server.
curl?easy_perfom() does not return in this case until a timeout occurs or
the socket gets closed. Actually, the server waits for some bytes of curl
here, probably being in the keep-alive mode. Just looking at this
"deadlock" on this communication socket, we seem to look at the same
problem, don't you think? I'm still investigating. It's a bit hard here to
reproduce it and isolate the appropriate request/response information to
compare with your findings.

Regards,

Cyrill

--On Freitag, 30. Mai 2003 09:50 -0400 RBramante_at_on.com wrote:

>
> 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

-------------------------------------------------------
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