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: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Fri, 2 Jul 2021 10:33:20 +0200 (CEST)
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?
If we would write an entire imaginary very basic "hello world" websockets
program using libcurl, what would it look like?
Date: Fri, 2 Jul 2021 10:33:20 +0200 (CEST)
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?
If we would write an entire imaginary very basic "hello world" websockets
program using libcurl, what would it look like?
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2021-07-02