Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



We can not use Caddy as long as a reliable and battle-tested rate limit module does not exist. "Work in progress" is not something I would like to put on a production system.

It would be great if you would like to finish the work on this project and make it part of the Caddy default distribution.

Honestly I do not understand how people run high-traffic sites without rate limiting. [D]DOS attacks and other misuse (e.g. spambots etc.) are daily issues on the internet, do you just ignore that?


Pasting a link from when we previously talked about this, for interest.

https://news.ycombinator.com/item?id=31439457

Appreciative of all the work regarding caddy, but the rate limiting seems to be chicken and egg, as few people seem to be willing to test it out in order for it to be accepted into core, and people are unwilling to test it out, because it's not in core.

It's also a blocker for me, so nginx wins by force of inertia.


Same for me. If it's not on core, means devs don't want to support it, which means it is buggy, therefore not ready for production.


No; if it's not in the core, that means we don't want to bloat the code base. Caddy is extensible for very good reasons!


Happy to finish it if a company would like to sponsor that work. It works well enough for what it was originally commissioned for. It actually will probably work pretty well for you as-is. Try it!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: