Buy commercial curl support. 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 Daniel himself.
Re: Libcurl and 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_lists.haxx.se>
Date: Tue, 21 Jan 2025 10:26:43 +0100 (CET)
On Mon, 20 Jan 2025, Gavin D. Howard via curl-library wrote:
> After rereading RFC 6455, and looking at the Curl Websocket API, I think
> that the only API change would be to add something like `CURLWS_SERVER` to
> `CURLOPT_WS_OPTIONS`.
As the entire libcurl API is for client-side, I'm not following how you would
make it act as a server just because you set CURLWS_SERVER ? The only way
libcurl can setup a WebSocket connection is as a client. How would you make it
act as a server?
I presume that you need a way to hook libcurl into a WebSocket connection in
the server after it has been setup by the client, or something like that. How
would that work?
> If that is set in the options, libcurl would not do any masking, but it
> would unmask any frames it receives.
There have been discussions about making a "mask-less" version of WebSocket
since it does not really add anything, so having an option that effectly
switches off masking is not unthinkable to me.
> As far as I can tell, the sole server-only API that libcurl might need
> would be in handling the upgrade request. For that, there needs to be:
>
> * Verify:
> * Request-URI
> * Host
> * Origin
> * A way to select which of the extensions to send back.
>
> But I think this can be done outside of libcurl, so if it is, the sole API
> change would be the addition of `CURLWS_SERVER`.
I don't think those features can be added to libcurl easily since they are
essential features and tasks for a server and also probably interacts with the
"normal" HTTP activities rather tightly.
But you would still need to "hook in" libcurl server-side into or onto the
connection somehow. I think that is the larger complication, isn't it?
One benefit with supporting server-side WebSocket would be that we could
probably write WebSocket test cases easier and let libcurl talk to itself in
both ends.
Date: Tue, 21 Jan 2025 10:26:43 +0100 (CET)
On Mon, 20 Jan 2025, Gavin D. Howard via curl-library wrote:
> After rereading RFC 6455, and looking at the Curl Websocket API, I think
> that the only API change would be to add something like `CURLWS_SERVER` to
> `CURLOPT_WS_OPTIONS`.
As the entire libcurl API is for client-side, I'm not following how you would
make it act as a server just because you set CURLWS_SERVER ? The only way
libcurl can setup a WebSocket connection is as a client. How would you make it
act as a server?
I presume that you need a way to hook libcurl into a WebSocket connection in
the server after it has been setup by the client, or something like that. How
would that work?
> If that is set in the options, libcurl would not do any masking, but it
> would unmask any frames it receives.
There have been discussions about making a "mask-less" version of WebSocket
since it does not really add anything, so having an option that effectly
switches off masking is not unthinkable to me.
> As far as I can tell, the sole server-only API that libcurl might need
> would be in handling the upgrade request. For that, there needs to be:
>
> * Verify:
> * Request-URI
> * Host
> * Origin
> * A way to select which of the extensions to send back.
>
> But I think this can be done outside of libcurl, so if it is, the sole API
> change would be the addition of `CURLWS_SERVER`.
I don't think those features can be added to libcurl easily since they are
essential features and tasks for a server and also probably interacts with the
"normal" HTTP activities rather tightly.
But you would still need to "hook in" libcurl server-side into or onto the
connection somehow. I think that is the larger complication, isn't it?
One benefit with supporting server-side WebSocket would be that we could
probably write WebSocket test cases easier and let libcurl talk to itself in
both ends.
-- / daniel.haxx.se || https://rock-solid.curl.dev -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-01-21