Sorry about that, stupid mistake on my side. I've fix the version on the server, an you can just edit the line to "pthread_detach(thread);" The snprintf() is only part of a status page, so you can remove it if you want.
As for the threads, that could be an issue if directly exposed to the internet: All it would take for an attacker to open a whole a whole bunch of connections and never send anything to OOM the process. However, this isn't possible if it's behind a reverse proxy, because the proxy has to receive all the information the needs server before routing the request. That should also filter out any malformed requests, which while I'm fairly sure the parser has sane error handling, it doesn't hurt to be safe.
Not sure if I agree with you on the thread exhaustion issue. The client can still send a flood of correctly-formed requests; the reverse proxy will pass them all through. As I said above, yes, the fact that babble processes requests so quickly would make this harder, but you could still end up with (tens of?) thousands of concurrent requests if someone is really determined to mess with you.
A solution could be to limit concurrent requests in the reverse proxy, but personally I prefer to write software that doesn't require another piece of software, configured correctly, to keep it safe.
And regardless, even with ~25 years of C experience under my belt, I don't think I'd ever be wholly comfortable exposing my C code to the internet, even behind a reverse proxy. Not coming at you directly with this, but I'm frankly skeptical of anyone who is comfortable with that, especially for a one-off service that won't see a lot of use and won't get a lot of eyeballs on it. (And I'm especially uncomfortable with the idea of posting something like this on a website and encouraging others to use it, when readers may not understand the issues involved.)
And yes, there is inherent risk with exposing any service to the internet. That goes for any program, written in any language (remember Log4Shell?) doing any task.
2. Wait for request <--- Attack causes us to get stuck here
3. Serve request
4. Close connection and thread / return to threadpool
Solution: Use a reverse proxy to handle the incoming connections. Typical reverse proxies such as nginx use event-based polling not a per-connection thread so they are immune to this issue.
The way you deal with this is that you write the server to be async I/O based with NPROC threads, not a thread-per-client design, and then you can use CPS for the business logic, but in this case it's so trivial... You can probably get by with just a handful of bytes of memory pressure per client in the app + whatever the per-client TCB is for the TCP connection for a total of less than 200 bytes per client.
I continuously encourage others to do exactly this. It is a great learning opportunity. If they are not aware that they will get DoS'd now they will know. It's not like they will get PTSD from having to wait for OOM killer or losing their vps. You learned it that way, I learned it that wat, why not others? At least this way they will have real experience under their belt, not some online diatribe.
As for the threads, that could be an issue if directly exposed to the internet: All it would take for an attacker to open a whole a whole bunch of connections and never send anything to OOM the process. However, this isn't possible if it's behind a reverse proxy, because the proxy has to receive all the information the needs server before routing the request. That should also filter out any malformed requests, which while I'm fairly sure the parser has sane error handling, it doesn't hurt to be safe.