replace-response VS caddy-ratelimit

> But there are many scenarios where being able to extend the HTTP server via Lua is more convenient than writing a plugin I would think?

Well, Caddy is written in Go, so it's only natural to write a plugin in Go. Statically compiled into your binary. We provide a tool called `xcaddy` which is used to produce builds of Caddy with any plugins you need. You just need Go installed on your system to run it, no other dependencies.

The reason why Lua is used for OpenResty is because writing plugins in C is... not fun.

You can absolutely do what you described with an HTTP handler module in Caddy. You'd just wrap the req.Body with a reader that watches the bytes as they're copied through the stream, and when you see the part you want to log, you do that.

We have a replace-response plugin which takes a similar approach, except it manipulates the response as it's being streamed back to the client. https://github.com/caddyserver/replace-response The whole plugin is just one file of Go code.

You can rate limit HTTP requests (agnostic of specific HTTP versions): https://github.com/mholt/caddy-ratelimit

If you can't already do it with the rate limit module I wrote, open an issue with your detailed requirements: https://github.com/mholt/caddy-ratelimit -- should be pretty straightforward for the most part.

> QoS for a shared-multitenant system, in the presence of customers with really badly tuned and spiky request workloads, whose traffic you must nevertheless mostly accept.

Yah, we see that sometimes. Caddy usually handles it fine, sometimes with a bit of massaging the config.

I'm using caddy for my web server due to it's awesome automatic certificate functionality using Let's Encrypt behind the scenes. Caddy supports rate limiting via this plugin so I don't have to worry about folks killing my API.