curl-library
Re: curl_easy_perform hangs on 7.9.8
Date: Fri, 30 May 2003 14:05:16 -0400
I put a hack into transfer.c Curl_readwrite() that fixes the problem for me
in the cases I mentioned. That function is a bit of a bear however (about
750 lines!), so there is a good possibility I may have broken something
else in the interim. Hopefully Daniel can have a look and see what he
thinks.
My (exceedingly simple) changes were to add the check:
else if(conn->size <= 0 && conn->maxdownload <= 0) {
data->set.no_body = TRUE;
k->keepon = 0;
}
to the existing
if (k->write_after_100_header) {
...
}
check after breaking out of the do/while(0) loop. The thinking being, if
the header reading is complete, there were no reads and no writes, and we
haven't set a download size, then there is probably nothing to read. Come
to think of it, maybe one additional check to make sure that it is not a
chunked-encoded transfer (conn->bits.chunk == FALSE) is also needed.
RBramante_at_on.com
Sent by: To: curl-library_at_lists.sourceforge.net
curl-library-admin_at_lists.sour cc:
ceforge.net Subject: Re: curl_easy_perform hangs on 7.9.8
05/30/2003 10:42 AM
Please respond to
curl-library
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
-------------------------------------------------------
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-31