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: Sun, 12 Jan 2025 21:27:51 +0000
> The problem with "limiting [an http server] to what you want" is that
> over time, the requirements will expand. Even if you think you know
> the limits won't change. They will, and the maintenance task that you
> - or your successor - will inherit from the technical debt will
> prevent you from doing more productive things with your (their) time.
> Or worse, you'll deal with avoidable CVEs.
>
> Seen this many times.
>
> Your "requests generated by browsers and libcurl" isn't particularly
> limiting. Which versions of which browsers and other clients? You'd be
> amazed at how many http clients there are - and what they uniquely
> expect/rely on.
>
> You're much better off using an existing server. You don't need to use
> a heavyweight server like Apache httpd or nginx; there are lightweight
> servers to choose from, and when there's an issue there are support
> resources.
>
> For example, thttpd. https://www.acme.com/software/thttpd/ or
> lighttpd: https://www.lighttpd.net/
>
> You can also find basic frameworks such as python's http.server or
> Perl's HTTP::Server::Simple or HTTP::Daemon.
>
> But I'd stick with a real server and put effort into a CGI.
> Reinventing the wheel is a bad investment.
I already have a FastCGI implementation that I was going to use behind a
real server, as you say.
But as far as I understand it, I still need to parse HTTP stuff with
that. Thus, I need to implement HTTP/1.1.
To answer Daniel:
> Exactly how would this new proposed look and work? I can't even fathom
> how an API for this would look like to be usable in a server setting.
That is a good question, and I don't expect you to answer it.
I will assume that asking the question is permission to at least try it.
I will come back ASAP with a rough API and a rough implementation. I
don't have much free time, though, so it may take some time.
Thank you.
Gavin Howard
Date: Sun, 12 Jan 2025 21:27:51 +0000
> The problem with "limiting [an http server] to what you want" is that
> over time, the requirements will expand. Even if you think you know
> the limits won't change. They will, and the maintenance task that you
> - or your successor - will inherit from the technical debt will
> prevent you from doing more productive things with your (their) time.
> Or worse, you'll deal with avoidable CVEs.
>
> Seen this many times.
>
> Your "requests generated by browsers and libcurl" isn't particularly
> limiting. Which versions of which browsers and other clients? You'd be
> amazed at how many http clients there are - and what they uniquely
> expect/rely on.
>
> You're much better off using an existing server. You don't need to use
> a heavyweight server like Apache httpd or nginx; there are lightweight
> servers to choose from, and when there's an issue there are support
> resources.
>
> For example, thttpd. https://www.acme.com/software/thttpd/ or
> lighttpd: https://www.lighttpd.net/
>
> You can also find basic frameworks such as python's http.server or
> Perl's HTTP::Server::Simple or HTTP::Daemon.
>
> But I'd stick with a real server and put effort into a CGI.
> Reinventing the wheel is a bad investment.
I already have a FastCGI implementation that I was going to use behind a
real server, as you say.
But as far as I understand it, I still need to parse HTTP stuff with
that. Thus, I need to implement HTTP/1.1.
To answer Daniel:
> Exactly how would this new proposed look and work? I can't even fathom
> how an API for this would look like to be usable in a server setting.
That is a good question, and I don't expect you to answer it.
I will assume that asking the question is permission to at least try it.
I will come back ASAP with a rough API and a rough implementation. I
don't have much free time, though, so it may take some time.
Thank you.
Gavin Howard
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-01-12