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.html
