> 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
