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: Gavin D. Howard via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 27 Jan 2025 18:57:58 +0000
> > 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/
Date: Mon, 27 Jan 2025 18:57:58 +0000
> > 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.htmlReceived on 2025-01-27