Hacker News Reader

Hacker News

Comment by heurisko | Hacker News Reader

Parent Full thread

heurisko

When I evaluated Caddy it was missing some features, such as rate limiting.

But I think Caddy is a fine server as well.

View on HN

Rate limiting plugin: https://github.com/mholt/caddy-ratelimit

Yes, I came across that. Didn't really compare to rate limiting in nginx, in terms of maturity or support.

> WORK IN PROGRESS: Please note that this module is still unfinished and may have bugs. Please try it out and file bug reports - thanks!

Sure, but it'll never reach maturity if you don't try it! We're always looking for more people to test things out, give their thoughts, and contribute ideas or fixes.

I think Caddy should adopt the module as a core module.

We may eventually do that, but we need evidence that it's actually useful for people, since it adds to the long-term maintenance burden if we bundle it.

Rate limiting is a life saving jacket, not some fancy nice-to-have feature.

Understood, but we don't want to ship something half-baked in the standard distribution. So we offer it as a plugin first so it can be worked on and polished without being tied to Caddy's versioning. Please try it out and give specific feedback on the plugin. We need to hear if there's any functionality missing or if the design doesn't fit user's needs before we can bundle it.

I look through my server logs sometimes and often see connection and request throttling being activated, by those who are hitting the servers with their automated exploit tools. I see having some sort of throttling as essential as being able to set the max client body file size to prevent abuse.

Of course, I could run something else in front of the server, but it's simpler for my use cases not to. The auto-SSL and simplified configuration were very attractive things about Caddy, however.

If your CMS provides it, maybe you could run an exit poll for people who demo Caddy, then look elsewhere, as I'm just speaking from my own experience.

Understood, I'm not saying it's not generally useful, I'm specifically talking about this implementation; is the way it was built useful, does it actually solve user's rate limiting needs? We need people to try to the plugin so we can mould it to user's needs. Then later we can bundle it once we're sure it's designed properly and we're locked-in on the approach taken.

Indeed, I see where you are coming from.

However I wonder if it would work better if the module were brought under the Caddy namespace and marked "beta".

At least then, there would be a show of commitment for the idea, if not the implementation.

Recently I've been looking at the Symfony framework, and this is how they introduce features, with a clear warning that the API etc. is subject to change.

I think that is the problematic point with Caddy right now - if you are using it, you are actually a beta tester. This is a problem for sites with lots of traffic because things start to be different with servers maxed out - Nginx is battle hardened, learned it´s lessons and you can be sure that it works under extreme load as expected.

Also you definitely need rate limiting out of the box, not as some beta plugin that needs to be fiddled in manually.

Also streaming is something that needs really good testing with high loads.

K8s is important for many people, too.

Of course it is not easy to find someone willing to test on a high traffic site when there are well established alternatives since many years and no actual problem needs to be solved.

"Easy configuration" is not very important for admins of high traffic sites. Not easy to find what could be the selling point for Caddy, but it should deliver one or two special things more.

Reply on news.ycombinator.com