Hacker News Reader

Comment by melx | Hacker News Reader

I did benchmark it against nginx and found Caddy to be 5-7x times slower, but like all benchmarks go...results are subject to ones requirements (or mistakes).

What got me away from using it:

- the directives feel intuitive but as soon as I needed a complex config it all became a chain of very implicit strings

- the caddy author(s) decided few years ago to add custom http header with their sponsors[0]. That header could not be removed, it's no longer present in current Caddy but the bad taste still remains.

[0] https://news.ycombinator.com/item?id=15238315

View on HN

My problem is that Caddy does not ship an X-Clacks-Overhead header by default.

I tried to submit the Caddy configuration for this to www.gnuterrypratchett.com, but looking at it, it doesn't seem like it was ever added to the site.

The configuration is simply:

Header X-Clacks-Overhead "GNU Terry Pratchett"

I don't think they are really competing with nginx. They are just in the sweetspot between convenience vs performance.

I just keep using HAProxy for doing the plumbing and keeping app side as simple as possible (which is often just "a web server builtin into app" + maybe static serving nginx if app is in slow language that can't handle serving statics quickly)

But automatic https does look convenient, no need to have separate certbot running

HAProxy 2.8 has improved[0] Let's Encrypt integration by using acme.sh (so you can get rid of certbot). It still needs a cron job/systemd timers to do renewal of certs but acme.sh is just bash script so you don't need (extra?) system deps for installing it, while certbot requires Python and 12 python libs on my system (Fedora). And nowadays the "recommended" way to get certbot is via Snap (package manager)...

[0] https://www.haproxy.com/blog/haproxy-and-let-s-encrypt

We use Caddy in production. The driving force for change was built in automatic https. It just simply works.

I'm happy to hear this -- we work hard on our auto-HTTPS features!

Haproxy is great in the end but it is pretty awful to work with. Once you've toiled in the mines of acl commands, going back to nginx/caddy is a breath of fresh air. Unless recent versions have completely changed the game, using haproxy when you don't have to is a massive time waster.

You can't expect a program in Go to compete with Rust or C++.

When they say it's "fast" they mean relative to something like Python.

I don't think language comparisons make sense here as a ton of performance is application dependent. So when it says it's "fast" it should be "fast" compared to many but not necessary all alternative similar software ignoring any language (which it probably is, some of the alternatives are not fast even through they are written in C AFIK).

Through in this case I would say it being "fast enough" for many use-cases is the relevant part.

I was under the impression GCed languages aren’t necessarily slower than non-GC. Rust still cleans up after itself (RAII and destructors). The difference is in latency, predictability and perhaps total memory use; but not actual speed, I thought.

The part you're missing is secondary effects of designing a language around GC. Most of the time, that means that everything is heap allocated. So even if a GC and RAII-style management did the same amount of work (and they generally don't, GC's often do less when allocating, for example) while doing allocation/deallocation, non-GC'd languages tend to allocate less in the first place. Additionally, if we're talking about overall performance, indirection can be quite bad on cache locality, so it's not even purely about the speed of allocation/deallocating, but about pointer chasing.

Some GC'd languages also offer tools to manage these problems, of course, all I mean to say is that there are a lot of factors at play here.

> it's no longer present in current Caddy but the bad taste still remains

Adding a sponsor header is harmless (albeit useless IMO). For me that would be no reason to not choosing this software, and certainly no ground for having a 'bad taste'.

What purpose does it actually fulfil? Who is actually looking at individual HTTP requests like this? All it does is take up extra traffic...

It's also a security risk if your web server is the only one doing it, as it is a way for an attacker to fingerprint the web server software in use.

I understand and agree with melx's view here completely, even if I do feel Caddy's strengths outweigh it's weaknesses.

> Who is looking

devs presumably

Which is exactly the audience we were targeting.

I thought it was a good idea at the time. ¯\_(ツ)_/¯

I think it’s a cool idea, though if it’s on by default, disabling it should be obvious like one of the first lines in the config file.

It is bad taste, unprofessional.

Taints the pool with the vibe of "We can do this; we will do this and you schmucks can't do anything about it because it's in the EULA".

Regardless to how harmless it is. It's still an unprofessional quality to implement such and then deny the ability to disable it.

Same example as if when you honked your cars horn it tooted the car model. You'd be annoyed right?

Sure, its harmless because how often do you use your car horn but you expect a car horn to horn not advertise the model your driving.

I'm imagining a Tesla's horn chiming the Intel "dah dah ding ding" thing now.

Let's hope Elon doesn't read this.

> Adding a sponsor header is harmless

Harmless or not - I think it's worth looking past this point. Maybe the http header was a way for them to search the internet and find *commercial* sites that didn't pay for Caddy license? Not very pro behaviour.

Caddy is licensed under the Apache license, which allows for commercial use. No one is infringing by not paying for the commercial version.

Well, we're in 2017 (read the thread I posted above), and in that year Caddy was distributing[0] the binary as licensed product. Apache licence applied to its source-code only (e.g. when you build the server from source - which only few people did).

[0] https://web.archive.org/web/20180216153020/https://caddyserv...

Thanks for the background. I didn't know it used to be like that. It's a funky licensing scheme if I ever saw one.

Reply on news.ycombinator.com