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: Fri, 2 Jul 2021 06:42:10 -0400
> On Jul 2, 2021, at 4:33 AM, Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se> wrote:
>
> On Thu, 1 Jul 2021, Weston Schmidt wrote:
>
>> I like the simplicity of the CURLOPT_CONNECT_ONLY=2L + ws:// or wss:// plan.
>>
>> If libcurl stops at the _The WebSocket Connection is Established_ point (https://datatracker.ietf.org/doc/html/rfc6455#page-20) when CURLOPT_CONNECT_ONLY=2L, then by definition that is only after the HTTP response 101 Upgrade stuff has happened. This means that redirects and other HTTP magic happens as normal. Libcurl then does not need to support or be altered for extensions or subprotocols.
>
> I think that's a decent plan for the initial bootstrap-into-websockets step. I could even imagine that CURLOPT_CONNECT_ONLY=2L could be implied by the explicit use of ws:// or wss:// in the URL.
>
> What's a little unclearer to me is what we need for the next phase, once the connection is done and setup. curl_easy_send/recv seem inadequate for websockets, which might imply that we need to provide curl_ws_send/recv. If so: A) how should they work and B) what else do we need?
The send interface could look much like curl_easy_send():
curl_ws_send( easy, buffer, buflen, &sent, enum curl_ws_message_type type, enum curl_ws_flags flags )
… where type is the frame type (as per the RFC) and where flags are:
CURL_WS_NOCOMPRESS - no-op if there’s no compression anyway
CURL_WS_MORE - omit WS’s FIN flag
The above assumes curl would hold a bit of state in order to sanity-check the calls and provide conveniences like auto-adding WS’s “initial” flag.
-----
Most WS libraries that I’ve seen implement reception as a callback, with a separate control to pause reception of incoming messages.
Maybe the following callback signature:
void curl_ws_on_recv_message( buffer, buflen, enum curl_ws_message_type type, enum curl_ws_flags flags )
… where “flags” would just be CURL_WS_NOCOMPRESS.
The “pause” could maybe be: curl_easy_setopt(easy, CURLOPT_WS_PAUSE, 1)?
Canonically, user applications aren’t meant to receive individual WS frames, but only entire messages. If, though, it’s desired that the client also be able to receive individual frames, perhaps the following:
void curl_ws_on_recv_frame( buffer, buflen, enum curl_ws_message_type type, enum curl_ws_flags flags )
-FG
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-07-02
Date: Fri, 2 Jul 2021 06:42:10 -0400
> On Jul 2, 2021, at 4:33 AM, Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se> wrote:
>
> On Thu, 1 Jul 2021, Weston Schmidt wrote:
>
>> I like the simplicity of the CURLOPT_CONNECT_ONLY=2L + ws:// or wss:// plan.
>>
>> If libcurl stops at the _The WebSocket Connection is Established_ point (https://datatracker.ietf.org/doc/html/rfc6455#page-20) when CURLOPT_CONNECT_ONLY=2L, then by definition that is only after the HTTP response 101 Upgrade stuff has happened. This means that redirects and other HTTP magic happens as normal. Libcurl then does not need to support or be altered for extensions or subprotocols.
>
> I think that's a decent plan for the initial bootstrap-into-websockets step. I could even imagine that CURLOPT_CONNECT_ONLY=2L could be implied by the explicit use of ws:// or wss:// in the URL.
>
> What's a little unclearer to me is what we need for the next phase, once the connection is done and setup. curl_easy_send/recv seem inadequate for websockets, which might imply that we need to provide curl_ws_send/recv. If so: A) how should they work and B) what else do we need?
The send interface could look much like curl_easy_send():
curl_ws_send( easy, buffer, buflen, &sent, enum curl_ws_message_type type, enum curl_ws_flags flags )
… where type is the frame type (as per the RFC) and where flags are:
CURL_WS_NOCOMPRESS - no-op if there’s no compression anyway
CURL_WS_MORE - omit WS’s FIN flag
The above assumes curl would hold a bit of state in order to sanity-check the calls and provide conveniences like auto-adding WS’s “initial” flag.
-----
Most WS libraries that I’ve seen implement reception as a callback, with a separate control to pause reception of incoming messages.
Maybe the following callback signature:
void curl_ws_on_recv_message( buffer, buflen, enum curl_ws_message_type type, enum curl_ws_flags flags )
… where “flags” would just be CURL_WS_NOCOMPRESS.
The “pause” could maybe be: curl_easy_setopt(easy, CURLOPT_WS_PAUSE, 1)?
Canonically, user applications aren’t meant to receive individual WS frames, but only entire messages. If, though, it’s desired that the client also be able to receive individual frames, perhaps the following:
void curl_ws_on_recv_frame( buffer, buflen, enum curl_ws_message_type type, enum curl_ws_flags flags )
-FG
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-07-02