cURL / Mailing Lists / curl-library / Single Mail


Re: HTTP Connection events

From: Daniel Stenberg <>
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?


List admin:

Received on 2014-01-30