On Mon, 27 Aug 2012, vmon wrote:

> I have a client program that manages the socket connection on its own using
> libevent's bufferevent. Now, I'd like to use libcurl to produce and send
> HTML GET requests on that socket, but let libevent read the reply.

I don't think that will be possible in a convenient way.

Why not let libcurl do the HTTP protocol which it was designed to and then you
can take care of the data once libcurl hands it to you?

> I can't let the bufferevent listener go and stay with libcurl, because it's
> a multi-protocol program, and I'm implementing the http part of it.

If you do the HTTP parts, then I'd say you shouldn't use libcurl. If you want
libcurl to help you with the HTTP parts, then I think you need to adapt to how
the libcurl API works.

> Does libcurl still listen to the socket for read events, even though I
> never ask it to do so? If yes, is there a way to tell libcurl to only
> write into the socket and then let it go?

libcurl is made to do HTTP requests, both sending them and receive the
response.

Btw: Don't use the word 'listen' to describe what libcurl does as a client, as
that's a term reserved for TCP servers. It makes things very confusing if you
say libcurl listens to sockets... libcurl will read data off the sockets, yes.
You cannot tell it to not do that.

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