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: Timothe Litt <litt_at_acm.org>
Date: Wed, 8 Jan 2025 11:30:18 -0500
On 07-Jan-25 10:32, Daniel Stenberg via curl-library wrote:
>> I've read the RFCs and just for HTTP 1.1, it seems simple enough to
>> implement it if I break Postel's law and essentially only accept
>> well-formatted HTTP requests, or requests as generated by browsers and
>> libcurl. Would it be simple enough to do myself? I really don't want to
>> pull in a full server library.
>
> 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.
Yes.
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.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Received on 2025-01-08
Date: Wed, 8 Jan 2025 11:30:18 -0500
On 07-Jan-25 10:32, Daniel Stenberg via curl-library wrote:
>> I've read the RFCs and just for HTTP 1.1, it seems simple enough to
>> implement it if I break Postel's law and essentially only accept
>> well-formatted HTTP requests, or requests as generated by browsers and
>> libcurl. Would it be simple enough to do myself? I really don't want to
>> pull in a full server library.
>
> 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.
Yes.
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.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature