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: About a websockets write callback

From: Weston Schmidt via curl-library <>
Date: Fri, 17 Jun 2022 06:12:21 -0700

I tend to agree that the existing function signature is a bit too restrictive.

If you don't want a unique to WS function, how about adding a different
variant across the board for folks?

What about adding a CURLOPT_CTX_WRITEFUNCTION where a
context object is passed that allows for access back to the curl object &
access to metadata that might be specific to that function call, etc.

If you want, you could replace the void *userdata with the ctx & then users
could make a curl_ctx_get_userdata(ctx) vs add more arguments.

For a WS, maybe only CURLOPT_CTX_WRITEFUNCTION is supported,
but maybe this is an alternative callback to the existing write() format one?


On Fri, Jun 17, 2022 at 5:59 AM Nicolas Mora via curl-library
<> wrote:
> Hello,
> Here are my 2 öre based on my implementation of a websocket library.
> Le 2022-06-17 à 07 h 39, Daniel Stenberg via curl-library a écrit :
> >
> > I would like to provide websockets data with the CURLOPT_WRITEFUNCTION
> > callback as well. But how would libcurl provide the additional necessary
> > metadata?
> >
> I assume when you talk about the CURLOPT_WRITEFUNCTION, it's related to
> an incoming websocket message from the server to libcurl.
> based on the write_callback definition, it's difficult to provide the
> metadata in it.
> For example, one could say that "for a websocket incoming message, the
> first write_callback call, the *ptr value will contain the message
> datestamp, the second call will contain the opcode, etc." Which would be
> hard for users to work with, at least.
> > My initial thought was to provide a special websocket function that only
> > can be used from within the callback that would provide the extra
> > information (type of data, opcode, and if the FIN bit is set or not
> > etc). Like maybe
> > 'curl_ws_metadata()'.
> >
> My best guess is to use a new curl option, something like
> CURLOPT_WS_WRITEFUNCTION with a specific write_callback callback.
> In this callback function libcurl would pass a pointer to a structure
> that will contain the message metadata. Those metadata would be
> accessible via the curl_ws_metadata() for example.
> Another advantage of a specific websocket callback function would be
> that this function will allow to manage the websocket entire communication.
> For example, a received message can be ignored by the app, or the app
> can disconnect the websocket if required, or send a message in answer to
> a received one, etc.
> /Nicolas
> --
> Unsubscribe:
> Etiquette:
Received on 2022-06-17