I've been using Caddy on some personal and community sites for around a year and it's worked out just great! The built in certificate management has been so nice compared to having to manage external letsencrypt tooling.
More recently I set up a VM at work to be a domain redirector for a bunch of typo domains to our main domains, since the old outsourced redirectors didn't have TLS, and it was dead simple!
I would appreciate better and consistent documentation to do more non-trivial things with Caddy, but for your basic use-cases it takes a lot of the pain away. Unfortunately, nginx and Apache still win on the (probably unfair) basis that they've got well over 10 years of history, and all of the cultural knowledge that comes with that.
Yeah, I feel that. I want to work on docs and knowledge-transfer a lot more in 2021. 2019 and 2020 were definitely full of sprinting to bring Caddy 2 up to par. I think in terms of major functionality it's settling down now, so docs and guides will be more feasible.
In the meantime, I always encourage anyone to contribute to our wiki: https://caddy.community/c/wiki/13 -- there's already lots of great topics there and room for plenty more, especially examples.
Hint: there's a LOT of market space for paid content to master the Caddy web server, if anyone reading this is looking to profit from their expertise...
Agreed, I almost mentioned documentation but I forgot... My use-cases are ridiculously simple, and it's definitely gotten way better in the last year, but just figuring out the syntax for putting my e-mail address in the config file and how to start the server without it asking me questions on stdin required some trial and error. Nothing major, but there just wasn't much on Google at the time.
Docs have gotten way better since. As has the install story. Before it was some scripted thing that I was never quite confident in, now it's a deb package that I feel confident in running updates and Ansible against. And honestly I have not had any problems since installing it.
Yes Caddy is fantastic. My favorite unexpected use case has been testing Apple webhooks and sign in, which requires TLS even for local development. Caddy made this so easy! I just set up DNS for my home address, configured my firewall to serve on public port 443 and fired up Caddy. Would have been endlessly more annoying to configure TLS for local development before Caddy. The config file for this is literally 3 lines:
How about supporting absolute hostnames? Even this site (https://news.ycombinator.com./) supports them just fine, only Caddy doesn’t. Caddy does it so badly that the HSTS preload for caddyserver.com is interpreted by browsers as applying to caddyserver.com. (which is correct), but caddy won't actually serve that spec-compliant website: https://caddyserver.com./ (just throws an SSL error)
The specification explicitly says what you want is the Wrong Thing™. The designers of SNI didn't leave this vague, they spelled it out first in RFC 3546 and most recently in RFC 6066
> "HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using ASCII encoding without a trailing dot. †
So, when your web browser sends the hostname "news.ycombinator.com." that's not an "absolute hostname" that's just an error. Maybe you can demand that web browsers stop doing that, but they'll likely tell you they don't care, and you should stop writing URLs incorrectly.
† The trailing dot rule was in every version, but earliest sources talked about using UTF8 because they pre-date the insight that all this backend (ie not human-facing) stuff can use A-labels which are ASCII and avoid any complicated Unicode problems. This version just says to use ASCII here.
It's not just SNI that's the issue. Caddy also can't handle Host headers with trailing dots, where the spec explicitly states those should be handled.
So while the SNI error is clearly on browsers (and bugs have been already filed), the Host header issue is clearly on caddy (which caddy sees as wontfix)
Honestly, in the 5+ years of Caddy, you're the only person I've ever seen complain about this. And you're relentless about it. You bring it up on every thread on HN that ever has a mention of Caddy. It's very annoying.
That said, you can just make a site block with that host label and Caddy will handle it just fine. You just need to explicitly ask Caddy for it.
This has been a shitty thread to read, tbh. It's clearly not pointless if there are improvements which could be made to make the product more spec-compliant, such as handling terminating dots in Host headers. And I'm saying this as someone who's never used Caddy for anything, ever.
This is all from four years ago. And kuschku hasn't taken no for an answer after all this time. It's frustrating and annoying to hear their complaints on every HN thread since.
I agree with you the thread is shitty. I'm just hoping being direct will end the trolling.
Is it "trolling" if one expects a webserver to work like every other webserver, even offering to make the required changes?
If you want to learn why supporting FQDNs is important, you can actually read the issue and PR on the traefik repo where they chose to add support for this:
Yes, because Caddy is not like every other webserver. It also automates TLS management, can act as an ACME server, etc.
You make it out to be a simple change, but it's really not. And the arguments for making any changes are not compelling enough to warrant the risks involved. Compliance for the sake of compliance is completely pointless.
> Yes, because Caddy is not like every other webserver. It also automates TLS management, can act as an ACME server, etc.
That’s why I’m comparing it to traefik, which can also automate TLS management, in the exact same way (even using the same libraries for most of the functionality, they’re after all both go webservers).
> And the arguments for making any changes are not compelling enough to warrant the risks involved
Why is it that you think you know better than the maintainers of e.g. traefik? It’s not like this is legacy functionality they kept around just for the sake of it, they added it in 2019 because there’s demand for it, today.
> even using the same libraries for most of the functionality
You're wrong. Caddy uses a superior library that's been more stress-tested at scale in production: https://github.com/caddyserver/certmagic and https://github.com/mholt/acmez - neither of which lego uses. Bugs and limitations in lego caused severe problems for several of our larger customers.
I’m not using caddy – but I get complaints that websites hosted on caddy servers don’t work with my tools, which follow the specs and require the absolute URL to work just as well as the relative one.
And I can’t remotely telepathically make all caddy users switch to nginx. So as long as a single HTTP server runs a version of caddy with this bug, I’ve got extra work to do, because the caddy people are wasting my time
Hello, ironically it was me who has created that issue some years ago. I saw that http://ai./ works in a browser and wondered why chagemann.de. doesn't. The culprit was caddy, and the caddy maintainer didn't want to fix it (or apparently accept PRs fixing it). Not sure where the trolling is supposed to be at.
More recently I set up a VM at work to be a domain redirector for a bunch of typo domains to our main domains, since the old outsourced redirectors didn't have TLS, and it was dead simple!