On Sun, 23 Feb 2014, Thomas Sanchez wrote:

> It is said that when curl_multi_socket_action is called it will call the
> CURLMOPT_SOCKETFUNCTION *if the status was updated*, this means, if the
> status is not updated the socket should be rescheduled to wait for the same
> type of event.

I like to see the events you wait for as persistent. You get informed by
libcurl about what to wait for, and those events should remain in place until
libcurl tells the application to remove them. So you don't really "reschedule"
events, you keep waiting for all the events libcurl has asked for until it
tells you to remove those events.

Of course, specific event library implementation details may call for events
to have to be set again, but that sounds like stupid design and I know there
are several event libs that don't work like that.

Is this a correct description of "asio" in this use case?

If your event lib works like that, I would suggest you keep a copy of the
events libcurl wants and their properties so that can set them again at will.

> To trigger the bug, one can simply modify the url to a complete google url
> like: http://www.google.fr/ which do not trigger a redirection but a
> complete page with a chunked response.

If you have any suggested improvements for the example, we'll be happy to
update it! I don't know much about asio and I'll admit I haven't studied the
asiohiper source code very carefully.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html