> > 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?
This is a good question, and one I failed to anticipate since I am still new to curl's design. 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. Yes, the socket itself wouldn't really be the option, since it's a boolean, but I think this would be a good way to pass the socket into libcurl. > > 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. Ah, I was not aware, but I hope such a version becomes reality. > > 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: > > > > ... > > 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. I agree. 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. Yes, I'd like to see libcurl add server stuff, but I also value its stability; that's why I want it as a dependency. I want the server stuff only added at the pace that you can sustain, and then only if WebSocket server support succeeds. I guess what I am trying to say is, if you don't accept my ideas, I will in no way feel slighted because libcurl is great as-is. > 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? I agree, but I also don't think it has to be a big complication. I noticed in [1] that you have a `switch` statement in `curl_easy_setopt()` (or used to), which means you probably can handle special code for one particular option. Handling an fd certainly would be special (that's the complication), but since you already have logic for special handling, I don't think it would be that complicated. Off the top of my head, you would need to: * Check that the pointer is not NULL (object pointer). * Check that the long value is within range (long). * Check that the fd value is valid (both cases, probably using something like `fcntl(fd, F_GETFD) != -1` or the Windows equivalent). > 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. Yes, absolutely, and as penance for being one of many people pushing libcurl to extend into the server realm, I am willing to not only implement my ideas (with your permission), but I will add those tests too. Gavin D. Howard Member and Manager Yzena, LLC [1]: https://daniel.haxx.se/blog/2024/10/27/decomplexifying-curl/ -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
