On Mon, 27 Jan 2025, Gavin D. Howard via curl-library wrote:
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?
However, after thinking it through, since the option is set through `curl_easy_setopt()`, I think the application could pass the already-connected TCP socket as the parameter, whether a pointer to it (as an object pointer) or cast to a long.
We use TLS these days, handing over a TCP socket is not enough. Handing over a TLS connection is a bit more involved.
It is also much more involved than just passing over the connection. A server has an event loop and juggles countless parallel connections. A websocket API needs to be adapted to work in such an environment. I'm not pretending I know what that would entail. I'm primiarly a client-side guy. I'm speculating.
I suppose it takes an implementation and use case to show how it can be done.
In fact, to be completely candid, adding this is a big risk to libcurl. It could be that it succeeds, and then you start getting demand to add true server-only stuff. This is the big reason I think Curl should *not* add the server upgrade logic; that will open the door and be even *more* of a gateway drug.
I am far from convinced about this "risk" of success. It depends on the specifics and timing. For example that the API works smoothly and allows for easy integration. Right now, it seems that no one of us are suitable persons to do this because we don't write a HTTP/ws server to integrate this in. And I would imagine that most servers that want websocket support already added it.
-- / daniel.haxx.se || https://rock-solid.curl.dev -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
