Re: Libcurl and WebSockets

> 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.html