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: curl websockets
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Felipe Gasper via curl-library <curl-library_at_cool.haxx.se>
Date: Wed, 23 Jun 2021 11:59:09 -0400
> On Jun 23, 2021, at 11:23 AM, Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se> wrote:
>
> On Tue, 22 Jun 2021, Weston Schmidt via curl-library wrote:
>
>> I'm interested in feedback or suggestions for what/how to define a good websocket API that complements libcurl.
>
> My very simple idea on how it could be added to the API:
>
> 1. We add another value to set CURLOPT_CONNECT_ONLY to (2). If this is used, and the URL is "http(s)://" then libcurl could "bootstrap" into a websocket connection.
>
> 2. Once it is completed, we could have the application extract the socket (to have something to wait on) and then use curl_easy_recv() and curl_easy_send() to receive and send websockets data over that connection.
>
> What would this be missing?
There’d be want, IMO, for interfaces that differentiate sending/receiving full messages versus per-frame. (And, of course, sending text versus binary, *maybe* flexibly enough to accommodate potential new message types were that ever to happen.) And callbacks for multi-mode?
Also the data from the close frame would probably be available via some new CURLINFO_* constants?
A couple other notes (having written a full WS library and a Perl binding for another):
- curl_easy_recv() would need either to poll under the hood or to do a socket timeout so that curl could send a ping if the local ping timeout happens midway through the recv.
- WebSocket compression is a per-message affair: one message can be compressed while the next is uncompressed.
- WS compression is also tunable; ideally those parameters should be configurable. (More specifically: WS’ deflate compression is tunable; any future compression schemes would probably also be.)
I’m excited to see this!
cheers,
-Felipe
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-06-23
Date: Wed, 23 Jun 2021 11:59:09 -0400
> On Jun 23, 2021, at 11:23 AM, Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se> wrote:
>
> On Tue, 22 Jun 2021, Weston Schmidt via curl-library wrote:
>
>> I'm interested in feedback or suggestions for what/how to define a good websocket API that complements libcurl.
>
> My very simple idea on how it could be added to the API:
>
> 1. We add another value to set CURLOPT_CONNECT_ONLY to (2). If this is used, and the URL is "http(s)://" then libcurl could "bootstrap" into a websocket connection.
>
> 2. Once it is completed, we could have the application extract the socket (to have something to wait on) and then use curl_easy_recv() and curl_easy_send() to receive and send websockets data over that connection.
>
> What would this be missing?
There’d be want, IMO, for interfaces that differentiate sending/receiving full messages versus per-frame. (And, of course, sending text versus binary, *maybe* flexibly enough to accommodate potential new message types were that ever to happen.) And callbacks for multi-mode?
Also the data from the close frame would probably be available via some new CURLINFO_* constants?
A couple other notes (having written a full WS library and a Perl binding for another):
- curl_easy_recv() would need either to poll under the hood or to do a socket timeout so that curl could send a ping if the local ping timeout happens midway through the recv.
- WebSocket compression is a per-message affair: one message can be compressed while the next is uncompressed.
- WS compression is also tunable; ideally those parameters should be configurable. (More specifically: WS’ deflate compression is tunable; any future compression schemes would probably also be.)
I’m excited to see this!
cheers,
-Felipe
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-06-23