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: Weston Schmidt via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 1 Jul 2021 20:21:37 -0700
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.
As Tomalak has pointed out, the rest of websocket is pretty trivial.
On Wed, Jun 30, 2021 at 11:57 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Wed, 30 Jun 2021, Weston Schmidt wrote:
>
> > Maybe this is a misunderstanding on my part, but I think (and my testing
> > seems to confirm) that CURLOPT_CONNECT_ONLY will stop at the first
> > connection to the first server encountered. If you have some other http
> > redirector in front of the ultimate server hosting the websocket, or the
> > websocket server returns 429 to indicate it's busy, try again later, the app
> > must then handle all this work (I think ... I certainly could be wrong).
>
> No, that's a correct understanding. CURLOPT_CONNECT_ONLY, as the name implies
> only does the connect part and then stops.
>
> The similarity it would share with websockets-in-curl is how it doesn't
> actually do any transfer, but will just do a controlled set of setting up
> protocol things and then return.
>
> > In my use cases, I'm generally asking libcurl to use HTTP to do redirection
> > and traffic reduction things with libcurl, then after the "exciting bits"
> > are done, I'd like to take ownership of the socket.
>
> And that's not a feature we have in current libcurl... but I don't think it
> would be too complicated to add if we end up deciding that's what we need.
>
> --
>
> / 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.html
Received on 2021-07-02
Date: Thu, 1 Jul 2021 20:21:37 -0700
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.
As Tomalak has pointed out, the rest of websocket is pretty trivial.
On Wed, Jun 30, 2021 at 11:57 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Wed, 30 Jun 2021, Weston Schmidt wrote:
>
> > Maybe this is a misunderstanding on my part, but I think (and my testing
> > seems to confirm) that CURLOPT_CONNECT_ONLY will stop at the first
> > connection to the first server encountered. If you have some other http
> > redirector in front of the ultimate server hosting the websocket, or the
> > websocket server returns 429 to indicate it's busy, try again later, the app
> > must then handle all this work (I think ... I certainly could be wrong).
>
> No, that's a correct understanding. CURLOPT_CONNECT_ONLY, as the name implies
> only does the connect part and then stops.
>
> The similarity it would share with websockets-in-curl is how it doesn't
> actually do any transfer, but will just do a controlled set of setting up
> protocol things and then return.
>
> > In my use cases, I'm generally asking libcurl to use HTTP to do redirection
> > and traffic reduction things with libcurl, then after the "exciting bits"
> > are done, I'd like to take ownership of the socket.
>
> And that's not a feature we have in current libcurl... but I don't think it
> would be too complicated to add if we end up deciding that's what we need.
>
> --
>
> / 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.html
Received on 2021-07-02