curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Send data before receiving data using the callback approach for WebSocket requests

From: Darshan Sen via curl-library <>
Date: Mon, 5 Jun 2023 18:32:29 +0530

Actually, I would still need this to work with the callback approach
because my application is required to work in a push-based mechanism, so
that it can allow users to attach callbacks to listen for received data
instead of a pull-based model where users would need to explicitly call my
APIs to pull in the received data. To be clear, I'm basically creating a
libcurl-based Node.js C++ addon <> for
the WebSocket JavaScript Web API
<> where users
should be able to attach callback handlers to process the received data and
explicitly call my APIs to send data.

On Mon, Jun 5, 2023 at 5:08 PM Darshan Sen <> wrote:

> Hi! I was experimenting with sending WebSocket requests using libcurl.
> Since my codebase already uses the callback approach for HTTP requests and
> I was just adding support for WebSocket connections, I thought of
> continuing using the same write callback for WebSocket connections too.
> However, I was trying to connect with a WebSocket server that expects the
> client to send data before responding. So I had a question:
> When using the callback approach
> <>,
> is it possible to run curl_ws_send() right after the connection is
> established, before the write callback function is executed for the first
> time?
> It isn't documented but I still tried setting CURLOPT_READFUNCTION to a
> valid read callback function but that didn't work, so I guess read
> callbacks are not expected to work when doing WebSocket requests. Does this
> mean that I would need to use the connect-only approach
> <>
> for WebSocket connections?
> Even if we find a solution for the callback approach, I was wondering if
> any of these approaches <> are
> recommended over the other?
> Thanks!

Received on 2023-06-05