Re: HTTP Connection events
Date: Thu, 30 Jan 2014 23:36:52 +0100 (CET)
On Thu, 30 Jan 2014, Jonathan Masters wrote:
> 1. Client GET HTTP.
> 2. HTTP server sends chunked messages. If this chunked message terminates
> with a 0 chunk, then there is a curl message in curl_multi_info_read. If
> this chunked message goes on forever, then there is never a message created,
> the user doesn't know the connection was successful.
> This is the problem I was facing, the server I am connecting to sends
> events, the connection is persistent and never dies. I technically know the
> connection is successful when I start receiving data, but as CURL knows this
> I thought it would be cleaner if curl created a message.
Thanks for your interest in helping out to improve libcurl!
Your mail made me remember the CURLINFO_XFER_STATE idea we played around with
before, and I rebased my patch and that's attached here for reference.
It isn't exactly what you ask for, but can be used to extract virtually the
same info - and more.
> As I've said before I'm no expert on CURL, but I've added the below which
> seems to work so far in multi.c, just after,
Your fix has multiple problems:
1 - if you do a request that re-uses a connection it will never trigger this
(that might not be a problem if just documented properly)
2 - CURLMSG_DONE is for when a transfer is done, you invent a new message
here and it shouldn't be *DONE
3 - you don't allocate a new message struct so if the transfer ends
immediately after, the struct will be overwritten with the "real"
CURLMSG_DONE message and I believe the multi->msglist may get ruined.
If the patch API is not enough and you really think an event is what's needed,
then I think we should consider building it more generically on top of the
state change logic in multi and it could use the states the
What do you say?
-- / daniel.haxx.se
- TEXT/x-diff attachment: 0001-CURLINFO_XFER_STATE-export-the-state-of-a-transfer.patch