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: Tue, 07 Jan 2025 17:43:46 +0000
> > I was wondering if the server portion of WebSockets could be implemented
> > minus the upgrade. I'd love to do it myself; would it be accepted if I did
> > it up to the standards of the Curl project?
>
> I can't see how that is libcurl's business. My mantra for curl has always been
> "client side only", so adding code that is exclusively for server-side seems
> to land on the wrong side of the fence.
I am a biased party, so feel free to trash this message.
However, I think the "client side only" part of libcurl is already dead,
and I think that you were the one to kill it.
(I say that with the *utmost* of respect [1], so sorry if it sounds
otherwise.)
The reason I think so is your own advice to not mix URL parsers I
previously mentioned. [2]
Say developers are working on a software system with both a client and a
server, such as:
* Slack
* Discord
* Matrix
* Git{Hub,Lab}
* Etc.
In those cases, then if they use libcurl for URL parsing in the client,
they should use libcurl for URL parsing on the server. In other words,
since you exposed the URL parser and gave that advice, you implicitly
encouraged people to use libcurl on the server.
On top of that, my server, not the client, is going to send email
(notifications to users), so libcurl, as an email client, would be in my
server anyway. Email is interesting because sending email is something
that servers do a lot, so they are often clients too.
WebSockets are another prime example; a client-facing server may be a
WebSocket client of another machine on a company's internal network.
Again, I am biased (although I am willing to help out!), but I think the
world would be incredibly blessed to have a libcurl that can be on both
ends of the network because servers are often clients themselves, and
using one library for both would reduce code duplication and attack
surface.
And if I were to appeal to your need for food and shelter, I think there
would be more companies willing to pay for professional support on
libcurl if they could use it on both ends because they would only need
support for one product instead of two. If I could afford it, I would be
*much* more likely to open my wallet in that case because that's the
only way I could afford it.
I think WebSockets would be a great pilot program for that since it's so
symmetrical, and I would bet there are already servers running it with
the raw API. If adding it does not work out, you could remove it in a
year or two like you are doing with Hyper and msh3.
> Implementing HTTP/1 proper is not easy. It is easy to get to the 90-95% mark.
> The remaining part can take a life-time. But yes, by limiting what you want to
> support and ignoring the rest, it can probably be done in a reasonable amount
> of effort. I'm guessing.
Wonderful, thank you. Yeah, I know that HTTP/1 proper is out of reach,
but all I need is a web interface that works in browsers and push/pull
through libcurl.
Gavin D. Howard
Member and Manager
Yzena, LLC
[1]: https://gavinhoward.com/2023/11/how-to-fund-foss-save-it-from-the-cra-and-improve-cybersecurity/#bootstrapping-the-plan
[2]: https://daniel.haxx.se/blog/2022/01/10/dont-mix-url-parsers/
Date: Tue, 07 Jan 2025 17:43:46 +0000
> > I was wondering if the server portion of WebSockets could be implemented
> > minus the upgrade. I'd love to do it myself; would it be accepted if I did
> > it up to the standards of the Curl project?
>
> I can't see how that is libcurl's business. My mantra for curl has always been
> "client side only", so adding code that is exclusively for server-side seems
> to land on the wrong side of the fence.
I am a biased party, so feel free to trash this message.
However, I think the "client side only" part of libcurl is already dead,
and I think that you were the one to kill it.
(I say that with the *utmost* of respect [1], so sorry if it sounds
otherwise.)
The reason I think so is your own advice to not mix URL parsers I
previously mentioned. [2]
Say developers are working on a software system with both a client and a
server, such as:
* Slack
* Discord
* Matrix
* Git{Hub,Lab}
* Etc.
In those cases, then if they use libcurl for URL parsing in the client,
they should use libcurl for URL parsing on the server. In other words,
since you exposed the URL parser and gave that advice, you implicitly
encouraged people to use libcurl on the server.
On top of that, my server, not the client, is going to send email
(notifications to users), so libcurl, as an email client, would be in my
server anyway. Email is interesting because sending email is something
that servers do a lot, so they are often clients too.
WebSockets are another prime example; a client-facing server may be a
WebSocket client of another machine on a company's internal network.
Again, I am biased (although I am willing to help out!), but I think the
world would be incredibly blessed to have a libcurl that can be on both
ends of the network because servers are often clients themselves, and
using one library for both would reduce code duplication and attack
surface.
And if I were to appeal to your need for food and shelter, I think there
would be more companies willing to pay for professional support on
libcurl if they could use it on both ends because they would only need
support for one product instead of two. If I could afford it, I would be
*much* more likely to open my wallet in that case because that's the
only way I could afford it.
I think WebSockets would be a great pilot program for that since it's so
symmetrical, and I would bet there are already servers running it with
the raw API. If adding it does not work out, you could remove it in a
year or two like you are doing with Hyper and msh3.
> Implementing HTTP/1 proper is not easy. It is easy to get to the 90-95% mark.
> The remaining part can take a life-time. But yes, by limiting what you want to
> support and ignoring the rest, it can probably be done in a reasonable amount
> of effort. I'm guessing.
Wonderful, thank you. Yeah, I know that HTTP/1 proper is out of reach,
but all I need is a web interface that works in browsers and push/pull
through libcurl.
Gavin D. Howard
Member and Manager
Yzena, LLC
[1]: https://gavinhoward.com/2023/11/how-to-fund-foss-save-it-from-the-cra-and-improve-cybersecurity/#bootstrapping-the-plan
[2]: https://daniel.haxx.se/blog/2022/01/10/dont-mix-url-parsers/
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-01-07