I’d be super interested to see what AFL does to this :)

To shreds, you say?

The author does mention that it's in the experimental stage, but I might make an attempt later just to refresh my AFL knowledge.

That sounds fun!

Can AFL test network applications without the need to modify their source code? If not, it should be easy to call the parsing routine in a loop using AFL's persistent mode.

At this time xHTTP only parses the minimum amount of headers to work, so fuzzing might not find much yet

IIRC the AFL docs recommend compile time instrumentation when the source is available. Binary-only fuzzing is possible, but it's a lot slower. My last binary-only attempt was years ago at this point, but I recall it being clunky to configure to the extent that I just dropped it in favor of instrumented source.

Can it handle gzip bombs, that is the real question :)

Overlaps with libmicrohttpd: https://www.gnu.org/software/libmicrohttpd/

Also overlaps with mongoose.{c,h} (GPL; not the MongoDB Mongoose) and its fork CivetWeb (MIT license).

https://github.com/cesanta/mongoose

https://github.com/civetweb/civetweb

This is neat but for convenience not performance. The bottleneck is in the kernel more than anything else. Probably it has the same latency as nginx, modulo safety checks. I would also recommend uWebSockets for an easy-to-embed web server.

That would be a lightning fast way to serve a simple multiuser chat. Any idea of the response rate per second you could achieve so close to the metal?

Does anyone know why the example went with a macro string “RESPONSE” rather than a char array or pointer?

Unnecessary optimization? At face value, it avoids calling strlen(). However, any modern compiler would be able to do that compile time anyway for static strings.