Yes, given that description is does sound more similar to my issue. The
difference I see is that I can easily reproduce it at will and as mentioned
the reuse of connections does seem to have anyhting to do with my problem.

I wrote a simple socket app here to test IE 6.0 against and for
expirementing. It basically just returns the response:

"HTTP/1.1 400 Bad Request\r\nContent-Type: text/html\r\nDate: Fri, 30 May
2003 13:47:25 GMT\r\nConnection: close\r\nServer: Apache Tomcat/4.0.3
(HTTP/1.1 Connector)\r\n\r\n"

Doing this will put curl into the loop state.

A couple other interesting points:

1) If I close the socket after sending this response things do not hang (as
expected from option #5 below).
2) If I add "Content-Length: 0" to my response header, IE 6.0 does not
hang, but curl still does, which *really* looks like a bug:
error [28] Operation timed out with 0 out of 0 bytes received. That just
seems wrong :-)

So, a couple possibilities to look at is if you are getting
"Content-Length: 0" responses from the server, or if you get responses
similar to the above.

                                                                                                                               
                      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 10:17 AM
                      Please respond to
                      curl-library
                                                                                                                               
                                                                                                                               

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

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