That’s it. That’s the whole thing. All the other settings are adjustable, but have the default values you’d configure yourself if you wanted to dig in and tweak it.
I appreciate Caddy immensely. It doesn’t do anything Nginx can’t do, as far as I know, but it’s a whole lot more ergonomic while doing it.
I think this focus on the default configuration of Caddy is a poor incentive, in a professional context. Here is the same config for nginx on a Debian box:
server {
server_name example.com;
root /var/www/wordpress;
location ~ \.php(/|$) {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php-version-fpm.sock;
}
ssl_certificate /etc/ssl/local/service.pem;
ssl_certificate_key /etc/ssl/local/service-key.pem;
}
It's very similar to Caddy's, except for the explicit cert.
No professional should care about a handful of extra lines. Anyway, in many real life situations, the config will be long and complex, whatever tool you use.
In the case above, the cert was created offline with the excellent mkcert from mkcert.dev, which is perfect for a developer machine. In other cases, I've had to use a certificate provided by my client. For the remaining cases, cerbot automates all, including nginx's config. Or if one installs the latest nginx, ACME cert retrieval is now included, so the difference to Caddy is shrinking.
I don't deny that Caddy is a worthy tool, but I don't care if it makes me write a few lines less in configuration files that I rarely write or update. Praise should focus on more important features.
[edit] The excellent leadership shown in this post seems more important!
Were the Nginx/Apache defaults bad at the time of creation? Has hardware changed? Security? Protocol versions?
Which is to say, in N years, will the Caddy defaults be full of some unfortunate decisions?
Caddy and Traefik have been around for a while now, so curious what has prevented the boring technology from essentially flipping some defaults around.
IMO a big reason is simply because they're written in C, which greatly slows down progress due to having to write a lot more code to do the same thing as higher level languages, and having to take significantly more care about memory safety issues. Caddy and Traefik being written in Go inherently solves both those problems, in addition to being built on top of Go's fantastic http and crypto stdlib packages which does the vast majority of the heavy lifting for implementing a compliant server. The remainder is mostly the config layer and middleware/admin/compatibility pieces (oversimplifying of course) which is where we can spend all our focus, being freed from having to be concerned about protocol level stuff (for the most part).
Admittedly there are some decisions we made with Caddy v2.0 that we would like to revisit eventually with a Caddy v3.0 in some future, but we haven't gotten to the point we've felt the need to plan that, most of those issues are minor enough that they haven't been deal-breakers. (And for context, v2.0 being a rewrite and rearchitecture from v0/v1 was necessary to unlock the potential that Caddy has realized today).
A little bit of all the above. I had to spend a lot more time configuring Nginx to use the recommended TLS algorithms. Caddy also supports HTTP/2 and HTTP/3 by default, no config required.
And those good defaults matter. If I pin down a set of TLS protocols today, will those still be good choices a couple of years from now? I don’t know. I’ll bet the then-current version of Caddy will still have good default settings. If HTTP/4 comes along, I suspect Caddy will configure it correctly on my site without me doing anything other than upgrading to a newer version, while other servers will want me to explicitly update their configs to enable it.
Yeah, I donate from time to time to various projects. But voluntary contributions will never solve this issue.
I had in mind somehow requiring or rewarding everyone to pay a small amount. Like, anyone who uses software from a platform such as GitHub should pay a subscription fee for maintenance depending on usage. It could be small so that it doesn’t interfere with usage. Considering huge number of users, that could pay for maintainers.
The point is, there are large number of users, if each user pays a small amount to the platform, they won’t notice it, yet it accumulates to a maintenance fee.
Paying a maintenance fee makes sense, regardless of how you label it. The entirely free software has problems and may not be sustainable.
As a core contributor, Matt has expressed on many occasions he would like to be able to pay us for all the time we've spent on the project, but I've always told him we're doing it as volunteers and not for money (my day job pays me sufficiently) and I think he needs it more since he doesn't have other sources of income. And if he did get enough from sponsorships to pay a second salary, I think he should hire someone not already a volunteer to broaden the skillset of the team. One of our biggest problems at this stage is that the members of the core team don't have expertise in a few specific areas that Caddy is lacking in (e.g. metrics/prometheus stuff)
Hey HN. Thanks for all the love and feedback. It's kind of a bittersweet decision; turning off notifications feels like closing your windows so you have to deliberately go outside to see what's going on. I like having the windows open. But too much was blowing in! Now I can better manage what I take on.
Anyway, I'm hoping this will help the project scale better on the development side. The community has shown that it can be responsible. Thanks for being a great part of it over the last 10+ years.
A stand-out feature has been ACME support built-in, and it’s a fairly capable reverse proxy. I’ve seen organizations use Caddy to provision certificates for customer domains at scale with very good results.
Personally, I much prefer the way caddy does configuration / plugins (as someone reasonably conversant in how nginx does those things) - comparable to "sysv init scripts vs systemd unit files".
I still think for Kubernetes ingress controller, traefik is more optimized for this use-case than Caddy. However, sitting in front of containers or a standalone reverse proxy I exclusively use Caddy.
>Now, the project is so stable and mature that most bugs require extensive explaining and troubleshooting, and very specific configurations, to reproduce.
There still remains this simple to reproduce bug where the page doesn't load of you use the full domain name of a site.
That form of domain name is very common in DNS configuration. All it means is the name is complete already and should not have any local search domains appended. It's unusual to see it in URLs, but its presence should be harmless; that it's not harmless in Caddy is definitely an error - but I can't begin to understand why it would be seen as a particularly significant one.
We get it, you have a grudge. No need to post this comment every single time anything related to Caddy is posted on HN. PRs welcome if you want to propose a change.
My 1st thought: The comment to which you are replying is why I'm not sure I'd have the patience to maintain an OS project. Though the older I get, the better I get at ignoring certain things.
My 2nd thought: Actually, this is very likely a culture/communication difference whereby both people care (I'm a big fan of Erin Meyer's work here)
My 4th though: Perhaps I can make 'enemies' become friends if they both have disdain for AI ;)
Note: I would absolutely not submit this as-is. Caddy's an amazing project though I am not very familiar with its implementation and I'd seek to understand it, conventions etc. and make some obvious improvements to the code which has been generated - but this was a minor bit of fun. I created 4 separate versions and only in one of them did anything with TLS related get amended.
I think it's unfair to say that I post this every time when I've only mentioned it twice before, with the previous time being 2 years ago. I don't have a grudge, I just recognize it as an easy to reproduce bug that disqualifies me from using the software. I'm not itching to get off of nginx as I already have a site that works, so I have no motivation to do extra work to fix bugs in other projects.
Still, only you and one other person with a similar grudge have ever complained about it (we've never had any github issues opened about it in years, neither on our forums) and nobody who cares has attempted to solve it with code changes.
Why would we work on something we don't care about, for free? If they paid a sponsorship, that would allow us (moreso Matt) to spend the time looking into it. Or, people complaining about it can spend their own time finding a solution rather than making noise like this. (Also - I didn't "pore over", I simply searched for "caddyserver.com." in HN's search and it turned up every time two specific individuals brought this up)
So maybe other people complaining are not using caddyserver.com domain?
I’ve seen people mentioning about dot at the end of the domain a few times this year. Also never knew is a valid domain and should be able to resolve. Some people mentioned before YouTube.com. Won’t load ads. But I think they fixed.
I've read every single Caddy forum post (up until some months ago where I decided I had to slow down for my mental health), every single Caddy issue in the past 7 years, and nearly every thread mentioning Caddy on HN in the a similar time span, and it's only ever been brought up on HN by exactly two people. I know the patterns and I know how to find those comments. You may be talking about threads not relating to Caddy, in which case I don't find that relevant.
Yes, I didn’t mean related to caddy. Just that dot at the end might not be so unusual like you said. TBH I don’t need this feature. I think it’s hard to be so sure only 2 people on hn mentioned this about caddy, unless you used a lot of resources to dig into it. To clarify I’m not against you, caddy is really amazing, just trying to be objective about it.
Caddy always worked well and recommended to other people. So I’m a pro caddy user, don’t get me wrong.
It's served this public to realize that there's obviously some serious flaw somewhere in the software that means fixing this isn't easy, or it would have been done.
We've not seen a good enough argument that it's worth our time investigating. This seems like something that only affects something like 0.00001% of users. It may be simple, but it also means extensive testing to make sure any kind of fix doesn't also break other things. With how extensive Caddy's usecases are, we have to be careful with any change, especially low-level ones involving TLS and host matching. We could accidentally introduce somekind of request smuggling security bug for example if proper care isn't taken.
It's ironic that you are bringing it up on a post about the toll that responding to issues is having on their mental health. I can see why it would strike a nerve if you do so on almost every front page post about Caddy.
We've felt attacked by people trying to slander the project due to this specific technical issue. It's exhausting. Either way, like I said, we'd be glad to accept contributions to solve this.
It's an awesome project and I imagine it has saved countless production incidents. The amount of times I've said "it was probably certificate expiry" and been correct is reasonably high.
In my own cases of responsibility, Caddy would have eliminated them had it been around. Instead I've learned to be paranoid, though having things like this are far better in terms of easing cognitive burden.
Cheers for all of the hard work by you and other maintainers.
I too have used Caddy on multiple production systems. It's a great bit of software.
I try to avoid engaging in online flame wars but I will say that the developers - including Francis - have been nothing but helpful and courteous to me personally and I've also learned a lot from their numerous positive contributions to Caddy-related forums.
What slander? What grudge? What attack? Until now I’ve been a happy user of Caddy but seeing you overreact like this to a mild mention of a bug is making me strongly reconsider.
If you haven't seen the history of this topic outside of this thread then you wouldn't understand how frustrating it's been to handle. I'd just like it to stop being brought up (without also offering help or a solution). Seriously, every time we either post something on HN ourselves regarding Caddy or find a thread posted from someone else, one of the first thoughts is "oh boy, are we gonna have to find issue brought up again?" Lo and behold, it was brought up again today.
Elsewhere in this thread you point out that he mentioned it in February last year. That was 18 months ago! They weren’t rude or abusive.
That is not a grudge. That is not slander. That is not a hill to die on. That is not an attack.
This makes me wonder how many other minor bugs are dismissed by you as a grudge due to you overreacting like this. It makes me a lot less confident in your project.
It’s perfectly fine for you to say ”this is low priority and we have no plans to fix it in the immediate future”. What’s not fine is treating it like a personal attack because they dared mention it twice in 18 months.
> This makes me wonder how many other minor bugs are dismissed by you as a grudge due to you overreacting like this. It makes me a lot less confident in your project.
This makes me wonder how many other discussion threads are wasted by this kind of complaints.
Overreaction to (alleged) overreaction never solves the problem!
Caddy doesn't hit the front page of HN all too often. But when it does, this issue gets brought up by one of two people. That's why it's annoying. It's so predictable and so annoying. We've already said our piece on the topic repeatedly, being asked to repeat ourselves again is insulting to us. Because "this is low priority and we have no plans to fix it in the immediate future" is clearly not an answer for someone who cares about this issue and mentions it again.
You are not the sole audience for this discussion. Just because they mention something you have heard before, it doesn’t mean they are deliberately taunting or provoking you. I’m glad they mentioned it. This thread gave me important new information about the project.
We're perfectly within our rights to express how it makes us feel for it to be brought up, especially with the history we've had around it. It's caused us a lot of grief and we'd just like for it to stop being shoved in our face. That's all. If it was brought up by someone totally unique (not repeated by the same person as before, who we've already answered) then I would have had a different, more tactful response.
I really don't think it's fair for you to make a judgement on me or the project from an interaction like this. At least judge the project on its technical merits. I've been very transparent here. But I can't stop you from having your thoughts. It is what it is.
> being asked to repeat ourselves again is insulting to us.
> we'd just like for it to stop being shoved in our face.
This is the comment you are referring to:
> There still remains this simple to reproduce bug where the page doesn't load of you use the full domain name of a site.
They aren’t asking you to repeat yourself. They aren’t shoving it in your face. This is an open discussion thread with many participants. They weren’t talking to you directly. This is information anybody here can find interesting and relevant. I did.
> I really don't think it's fair for you to make a judgement on me or the project from an interaction like this. At least judge the project on its technical merits.
How you are reacting to this is far more important to me than the original bug.
Remember when 37signals suffered data loss because they were using GET requests to delete things? When people pointed out they had a bug, they were offended and blamed GWA. What happened next? The same thing happened all over again, users suffered more data loss.
Or how about when Naomi Wu reported a problem with Signal, where the common use case of third-party keyboards for Chinese people was rendering all of their security worthless? They dismissed that as somebody with a grudge and ignored her for a year. What happened next? People found out that Chinese keyboards were compromised; she was 100% right, and Signal users were in danger.
I’ve seen what happens when people have this attitude towards inconvenient people reporting inconvenient bugs. It’s a danger to users, and you are making Caddy seem dangerous with this attitude. I was a happy user of Caddy right up until this thread, and even halfway down this thread – even after reading the mention of the bug – but your reaction has flipped that to the opposite because I can’t trust that there aren’t more bugs you are handling this way.
This is being blown out of proportion. You're discounting an entire project and your experience of the software over a person expressing exasperation over an inconsequential feature (not a bug) that even the author of curl had his run through and frustration. The request was not dismissed, rather it was discussed at length on our issue tracker. The OP knows it was discussed at length because they linked to the discussion thread in the earlier times they brought this up. Moreover, the way they presented it this time is snide, agree or not. To quote Matt's statement of the project being "stable and mature" just to say "except you didn't implement my niche feature" (yes, editorialized) is not criticism nor a feature request. It's veiled instigation hiding behind plausible deniability.
Anyways, on the feature request, Caddy is not the only software who disagrees with it being valid, and curl had their back-and-forth on it. There's no legitimate bug being dismissed, and you can go through the issue tracker to audit it. Equating this discussion with 37signals or Signal is false equivalence.
It's a repeat complaint from the same person who admits bringing it up before. The way they framed their complaint is, again, snide.
> That’s a long way beyond exasperation, that’s a massive overreaction.
Your reaction to Francis is _the_ overreaction. Francis simply said to OP to put their money where their mouth is. The "slander" comment comes later as a general statement on why this subject has become annoying.
Stop being hung up on Francis' response. The niche feature was discussed at length multiple times. You're welcome to search the web for all the conversations we had on the subject. Caddy has been around for 11 years. We've seen this subject more than you've seen it brought up. Again, OP referenced the discussion on the issue tracker in one of the earlier times they brought it up. They _admit_ it's niche. What's the point of continuously bringing it up?
Okay, so the last time was 18 months ago not two years. But do you really think that mentioning it three times in 3.5 years can fairly be described as a grudge?
> Stop being hung up on Francis' response.
This is the only thing that matters to me in this thread. The bug itself is not that interesting. It’s a big deal to me that your team seems to take even the mildest mention of a bug as some kind of harassment. I’ve seen that kind of attitude before, and it’s dangerous.
Yes calling it a grudge is kneejerk, but no I won't apologize for it because of how intensely frustrating the prior discussions (and today's, no help to you) were to deal with (take today's, multiply it by two for the intensity, then multiply it by ten for the amount of times it happened). You aren't me, you don't know what I've experienced and you don't know all the details, so please stop making assumptions.
It's the fact they bring it up again when we've made it clear our stance is the problem, not so much the actual words in today's post. It's also off-topic (not relating to project maintainership) and it's on a post I submitted myself to HN.
I know you've already made up your mind, but look at our track record of answering support questions on the forums and tickets on GitHub, and you'll see that the picture you've formed in your mind from this thread is not accurate.
Those comparisons are very straw-man and I won't entertain them. As I've already said, IMO there's more risk in introducing a new security bug in trying to fix this issue than there is leaving it as-is (failing fast and hard).
> It's the fact they bring it up again when we've made it clear our stance is the problem
You are still locked into this idea that the sole purpose of bringing it up is for your response. This is an open conversation, not a dialogue between only you and them. It doesn’t matter if you have made your stance clear, them bringing it up gives other people a chance to hear about it and discuss it.
> I know you've already made up your mind, but look at our track record of answering support questions on the forums and tickets on GitHub, and you'll see that the picture you've formed in your mind from this thread is not accurate.
To be clear: my mind was made up that Caddy was a good, reliable choice, and it was your behaviour in this thread that changed my mind, it wasn’t my imagination.
> IMO there's more risk in introducing a new security bug in trying to fix this issue than there is leaving it as-is (failing fast and hard).
I believe that, but I also believe your attitude is a bigger threat to security than either.
And you're still locked into this idea that you'll convince me that I shouldn't care, when I've expressed how it makes me feel due to the history. Can you respect that there are topics I'd just like not to be reminded of in a certain way? If it was brought up in a _constructive_ way, I would accept it (i.e. offering help or a solution via a PR with tests). If it was brought up by someone who I didn't specifically interact with negatively on this topic before, I would accept it.
> I believe that, but I also believe your attitude is a bigger threat to security than either.
I can't change your belief, nor do I care to, but I think that's absurd. Show me an actual security threat relating to this and I will address it. But this problem as stated is not one.
You keep saying that, but you did change my belief! My opinion is not immutable, I listen to what people say, and that is the reason we have ended up here. Because I listened to you and you convinced me to change my mind about Caddy.
> Show me an actual security threat relating to this and I will address it. But this problem as stated is not one.
“This problem” that I’m concerned with is your attitude not the FQDN bug, and I already gave the Signal example. When you start perceiving people reporting bugs as attacks and grudges, it makes it dangerously easy to dismiss real problems.
If that person found another problem with Caddy, I think they are less likely to report it to you because of this. If they did report it, I would think you are very likely to dismiss it because of who they are, not the contents of the bug report. This is a serious problem for my trust in Caddy.
I thought I was clear enough about this already, but clearly not: I encourage anyone who believes there's a bug with Caddy to report it to us on GitHub, where bug reports belong, where we can have focused discussion about it and see it to its natural conclusion. I do not discriminate bug reports based on who makes it.
An HN thread is not the place to report a bug. Nor do I think it's fair to form opinions about project maintenance (which doesn't happen on HN) based on comments in HN.
> If that person found another problem with Caddy, I think they are less likely to report it to you because of this.
Given they're aware of previous discussion and the stance on the feature request, I don't think they're deterred by the discussion here. Your addition of fuel to fire here is the very thing that's not helping.
> If they did report it, I would think you are very likely to dismiss it because of who they are, not the contents of the bug report.
People are allowed to crticize a project whether or not they want to fix it. It was a mild, brief mention of one issue. Accurate, too, so not slander.
You seem to think there is a conspiracy against Caddy. That seems doubtful. But I could see disproportionate defensiveness like what is on display here causing some people to not be fans.
Two people don’t make a conspiracy. And honestly, the tone came off as pretty snide. Quoting part of the post just to twist it into their own point was clearly deliberate.
I've worked in a technical support forum with usually great guys, but what happened there was that specific complaints and specific users became designated the enemy of the group, by the group. Everything in contact with the specific issues or the specific users became twisted beyond recognition, and the group reacted to it always with aggressiveness. The "problem users" usually left after some time, then the group magically choose the next victim.
From the outside, such a group mechanism is happening here. Your reaction to the issue being brought up is not rational, and from the outside not understandable. Even if it was brought up 18 month before in the same way. And no, the curl post does not match your hostility. And no, the tone did not came off as "pretty snide", even if tribal voting pattern greys out your opposition anyway.
Please reconsider your approach here. If the issue is not fixable in caddy (though Apache seems to handle it fine?) maybe formulate a standard response that says something like "sorry, this is complicated, see the curl explication here" and leave it at that. Have an action plan that recognizes group dynamics and the burnout symptoms existing in the project, as mentioned in the article.
It’s nice to see the responsibility spread across more people, open source projects live and die by their maintainers.
As a note, Caddy is one of those tools which hits the 80-90% of functionality with 50% of the complexity.
For both my homelab and hobby projects it just works. Its configuration is sane and well documented.
I highly recommend giving it a try.
For those on the fence, imagine Nginx, but with all the defaults set to what you’d have them on in the first place.
Here’s a complete configuration file for a Wordpress site with a LetsEncrypt TLS cert, static files, and PHP executed via FastCGI:
That’s it. That’s the whole thing. All the other settings are adjustable, but have the default values you’d configure yourself if you wanted to dig in and tweak it.I appreciate Caddy immensely. It doesn’t do anything Nginx can’t do, as far as I know, but it’s a whole lot more ergonomic while doing it.
I think this focus on the default configuration of Caddy is a poor incentive, in a professional context. Here is the same config for nginx on a Debian box:
It's very similar to Caddy's, except for the explicit cert.No professional should care about a handful of extra lines. Anyway, in many real life situations, the config will be long and complex, whatever tool you use.
In the case above, the cert was created offline with the excellent mkcert from mkcert.dev, which is perfect for a developer machine. In other cases, I've had to use a certificate provided by my client. For the remaining cases, cerbot automates all, including nginx's config. Or if one installs the latest nginx, ACME cert retrieval is now included, so the difference to Caddy is shrinking.
I don't deny that Caddy is a worthy tool, but I don't care if it makes me write a few lines less in configuration files that I rarely write or update. Praise should focus on more important features. [edit] The excellent leadership shown in this post seems more important!
Were the Nginx/Apache defaults bad at the time of creation? Has hardware changed? Security? Protocol versions?
Which is to say, in N years, will the Caddy defaults be full of some unfortunate decisions?
Caddy and Traefik have been around for a while now, so curious what has prevented the boring technology from essentially flipping some defaults around.
IMO a big reason is simply because they're written in C, which greatly slows down progress due to having to write a lot more code to do the same thing as higher level languages, and having to take significantly more care about memory safety issues. Caddy and Traefik being written in Go inherently solves both those problems, in addition to being built on top of Go's fantastic http and crypto stdlib packages which does the vast majority of the heavy lifting for implementing a compliant server. The remainder is mostly the config layer and middleware/admin/compatibility pieces (oversimplifying of course) which is where we can spend all our focus, being freed from having to be concerned about protocol level stuff (for the most part).
Admittedly there are some decisions we made with Caddy v2.0 that we would like to revisit eventually with a Caddy v3.0 in some future, but we haven't gotten to the point we've felt the need to plan that, most of those issues are minor enough that they haven't been deal-breakers. (And for context, v2.0 being a rewrite and rearchitecture from v0/v1 was necessary to unlock the potential that Caddy has realized today).
A little bit of all the above. I had to spend a lot more time configuring Nginx to use the recommended TLS algorithms. Caddy also supports HTTP/2 and HTTP/3 by default, no config required.
And those good defaults matter. If I pin down a set of TLS protocols today, will those still be good choices a couple of years from now? I don’t know. I’ll bet the then-current version of Caddy will still have good default settings. If HTTP/4 comes along, I suspect Caddy will configure it correctly on my site without me doing anything other than upgrading to a newer version, while other servers will want me to explicitly update their configs to enable it.
For me it's been 95% and 5%. Caddy is great!
Caddy rules, i can't imagine using anything else for the kind of projects I'm usually involved with.
I've had a really good time with Caddy on a hobby project over the past 7 years on a digital ocean droplet.
Automatic HTTPS, multiple domains, proxying specific routes to local services, etc etc, managed by one extremely legible config file.
I've had literally one service failure over that period, and it was my own error after running upgrades of the droplet's operating system.
Highly recommended.
Congrats to Mike on growing the project to the point where he can responsibly take a hand off the wheel now and then. And thank you!
> Congrats to Mike...
It's actually Matt :)
Haha, hi Mike!
(He and I were coworkers for a time.)
This is too cute.
Caddy is excellent. Great on you, Matt for giving up some control.
Free software needs to find a way to encourage people to contribute so that maintainers get paid.
Caddy has been great!
You can sponsor Mike right on GH!
https://github.com/sponsors/mholt
*Matt btw
Oh wow. I just wrote a test that needed to parse CSV, and PapaParse was the perfect library for it.
Sponsoring right away.
Just saw that come in. Thank you!
Yeah, I donate from time to time to various projects. But voluntary contributions will never solve this issue.
I had in mind somehow requiring or rewarding everyone to pay a small amount. Like, anyone who uses software from a platform such as GitHub should pay a subscription fee for maintenance depending on usage. It could be small so that it doesn’t interfere with usage. Considering huge number of users, that could pay for maintainers.
We already have that, it's called paid/proprietary software
That’s mostly different.
The point is, there are large number of users, if each user pays a small amount to the platform, they won’t notice it, yet it accumulates to a maintenance fee.
Paying a maintenance fee makes sense, regardless of how you label it. The entirely free software has problems and may not be sustainable.
That is not at all what they said. Your interpretation seems disingenuous.
Maybe it's time to try Flattr again?
(And this time with a solid option for companies too!)
Will contributors get paid too?
As a core contributor, Matt has expressed on many occasions he would like to be able to pay us for all the time we've spent on the project, but I've always told him we're doing it as volunteers and not for money (my day job pays me sufficiently) and I think he needs it more since he doesn't have other sources of income. And if he did get enough from sponsorships to pay a second salary, I think he should hire someone not already a volunteer to broaden the skillset of the team. One of our biggest problems at this stage is that the members of the core team don't have expertise in a few specific areas that Caddy is lacking in (e.g. metrics/prometheus stuff)
Matt has been generous and rewarded me a few times for my efforts on the project. But just as Francis said, we are willing volunteers.
Hey HN. Thanks for all the love and feedback. It's kind of a bittersweet decision; turning off notifications feels like closing your windows so you have to deliberately go outside to see what's going on. I like having the windows open. But too much was blowing in! Now I can better manage what I take on.
Anyway, I'm hoping this will help the project scale better on the development side. The community has shown that it can be responsible. Thanks for being a great part of it over the last 10+ years.
I like Caddy. Good to see it evolve. Hope it works well
I want to use Caddy as an ingress or gateway in Kubernetes.
I have not configured lone servers in a long long time
https://caddyserver.com/
> The Ultimate Server
> makes your sites more secure, more reliable, and more scalable than any other solution.
Is this an alternative to nginx or something?
It’s an http server like Apache or nginx.
A stand-out feature has been ACME support built-in, and it’s a fairly capable reverse proxy. I’ve seen organizations use Caddy to provision certificates for customer domains at scale with very good results.
Yes.
Personally, I much prefer the way caddy does configuration / plugins (as someone reasonably conversant in how nginx does those things) - comparable to "sysv init scripts vs systemd unit files".
I've never used caddy but "better config than nginx" is a pretty low bar.
It is, but I've mostly came across Caddy as a traefik alternative.
I still think for Kubernetes ingress controller, traefik is more optimized for this use-case than Caddy. However, sitting in front of containers or a standalone reverse proxy I exclusively use Caddy.
>Now, the project is so stable and mature that most bugs require extensive explaining and troubleshooting, and very specific configurations, to reproduce.
There still remains this simple to reproduce bug where the page doesn't load of you use the full domain name of a site.
https://caddyserver.com./
Never in my life have I seen a domain with a dot at the end OR a dot at the end with a slash.
bananas
why is this your hill to die on?
That form of domain name is very common in DNS configuration. All it means is the name is complete already and should not have any local search domains appended. It's unusual to see it in URLs, but its presence should be harmless; that it's not harmless in Caddy is definitely an error - but I can't begin to understand why it would be seen as a particularly significant one.
The correct way to write a fully qualified domain name is with a period at the end otherwise it’s subject to the resolver search path.
you're right, I have seen the end dot in DNS configuration. I was a bit snarky in my reply.
We get it, you have a grudge. No need to post this comment every single time anything related to Caddy is posted on HN. PRs welcome if you want to propose a change.
My 1st thought: The comment to which you are replying is why I'm not sure I'd have the patience to maintain an OS project. Though the older I get, the better I get at ignoring certain things.
My 2nd thought: Actually, this is very likely a culture/communication difference whereby both people care (I'm a big fan of Erin Meyer's work here)
My 3rd thought: I wonder what happens if I provide this repo and the chat comments to codex. Outcome: https://github.com/wsimmonds/caddy/pull/1
My 4th though: Perhaps I can make 'enemies' become friends if they both have disdain for AI ;)
Note: I would absolutely not submit this as-is. Caddy's an amazing project though I am not very familiar with its implementation and I'd seek to understand it, conventions etc. and make some obvious improvements to the code which has been generated - but this was a minor bit of fun. I created 4 separate versions and only in one of them did anything with TLS related get amended.
I think it's unfair to say that I post this every time when I've only mentioned it twice before, with the previous time being 2 years ago. I don't have a grudge, I just recognize it as an easy to reproduce bug that disqualifies me from using the software. I'm not itching to get off of nginx as I already have a site that works, so I have no motivation to do extra work to fix bugs in other projects.
Last year: https://news.ycombinator.com/item?id=39474419 and you also said "I have only brought this up once before on HN and it was over 2 years ago." in that same thread.
Still, only you and one other person with a similar grudge have ever complained about it (we've never had any github issues opened about it in years, neither on our forums) and nobody who cares has attempted to solve it with code changes.
I'll admit I don't have perfect memory of my comments. I'll also admit this is a niche feature.
Instead of poring over this person’s history maybe fix the bug?
Why would we work on something we don't care about, for free? If they paid a sponsorship, that would allow us (moreso Matt) to spend the time looking into it. Or, people complaining about it can spend their own time finding a solution rather than making noise like this. (Also - I didn't "pore over", I simply searched for "caddyserver.com." in HN's search and it turned up every time two specific individuals brought this up)
So maybe other people complaining are not using caddyserver.com domain?
I’ve seen people mentioning about dot at the end of the domain a few times this year. Also never knew is a valid domain and should be able to resolve. Some people mentioned before YouTube.com. Won’t load ads. But I think they fixed.
I've read every single Caddy forum post (up until some months ago where I decided I had to slow down for my mental health), every single Caddy issue in the past 7 years, and nearly every thread mentioning Caddy on HN in the a similar time span, and it's only ever been brought up on HN by exactly two people. I know the patterns and I know how to find those comments. You may be talking about threads not relating to Caddy, in which case I don't find that relevant.
Yes, I didn’t mean related to caddy. Just that dot at the end might not be so unusual like you said. TBH I don’t need this feature. I think it’s hard to be so sure only 2 people on hn mentioned this about caddy, unless you used a lot of resources to dig into it. To clarify I’m not against you, caddy is really amazing, just trying to be objective about it.
Caddy always worked well and recommended to other people. So I’m a pro caddy user, don’t get me wrong.
I am sure, because of how front of mind it has been every time it's been brought up (not just to me, but everyone on the Caddy core team).
We appreciate the recommendations! :)
Ok fine, instead of poring over someone’s comment history why not enjoy some free time?
Because leaving comments like that unaddressed/unclarified does not serve the public reading this thread.
It's served this public to realize that there's obviously some serious flaw somewhere in the software that means fixing this isn't easy, or it would have been done.
Which is sad, as now I have to reconsider.
We've not seen a good enough argument that it's worth our time investigating. This seems like something that only affects something like 0.00001% of users. It may be simple, but it also means extensive testing to make sure any kind of fix doesn't also break other things. With how extensive Caddy's usecases are, we have to be careful with any change, especially low-level ones involving TLS and host matching. We could accidentally introduce somekind of request smuggling security bug for example if proper care isn't taken.
It's ironic that you are bringing it up on a post about the toll that responding to issues is having on their mental health. I can see why it would strike a nerve if you do so on almost every front page post about Caddy.
You responded to a specific technical observation stated briefly and without emotion with a nasty personal attack.
Oh and now I see you work on the project. Hard pass on Caddy if this is how you respond to mild criticism.
We've felt attacked by people trying to slander the project due to this specific technical issue. It's exhausting. Either way, like I said, we'd be glad to accept contributions to solve this.
It's an awesome project and I imagine it has saved countless production incidents. The amount of times I've said "it was probably certificate expiry" and been correct is reasonably high.
In my own cases of responsibility, Caddy would have eliminated them had it been around. Instead I've learned to be paranoid, though having things like this are far better in terms of easing cognitive burden.
Cheers for all of the hard work by you and other maintainers.
I too have used Caddy on multiple production systems. It's a great bit of software.
I try to avoid engaging in online flame wars but I will say that the developers - including Francis - have been nothing but helpful and courteous to me personally and I've also learned a lot from their numerous positive contributions to Caddy-related forums.
What slander? What grudge? What attack? Until now I’ve been a happy user of Caddy but seeing you overreact like this to a mild mention of a bug is making me strongly reconsider.
If you haven't seen the history of this topic outside of this thread then you wouldn't understand how frustrating it's been to handle. I'd just like it to stop being brought up (without also offering help or a solution). Seriously, every time we either post something on HN ourselves regarding Caddy or find a thread posted from someone else, one of the first thoughts is "oh boy, are we gonna have to find issue brought up again?" Lo and behold, it was brought up again today.
If you want another vote for how annoying the trailing dot issue is in general, hear it from no other than the author of Curl, Daniel Stenberg himself https://daniel.haxx.se/blog/2022/05/12/a-tale-of-a-trailing-...
Elsewhere in this thread you point out that he mentioned it in February last year. That was 18 months ago! They weren’t rude or abusive.
That is not a grudge. That is not slander. That is not a hill to die on. That is not an attack.
This makes me wonder how many other minor bugs are dismissed by you as a grudge due to you overreacting like this. It makes me a lot less confident in your project.
It’s perfectly fine for you to say ”this is low priority and we have no plans to fix it in the immediate future”. What’s not fine is treating it like a personal attack because they dared mention it twice in 18 months.
> This makes me wonder how many other minor bugs are dismissed by you as a grudge due to you overreacting like this. It makes me a lot less confident in your project.
This makes me wonder how many other discussion threads are wasted by this kind of complaints.
Overreaction to (alleged) overreaction never solves the problem!
Caddy doesn't hit the front page of HN all too often. But when it does, this issue gets brought up by one of two people. That's why it's annoying. It's so predictable and so annoying. We've already said our piece on the topic repeatedly, being asked to repeat ourselves again is insulting to us. Because "this is low priority and we have no plans to fix it in the immediate future" is clearly not an answer for someone who cares about this issue and mentions it again.
You are not the sole audience for this discussion. Just because they mention something you have heard before, it doesn’t mean they are deliberately taunting or provoking you. I’m glad they mentioned it. This thread gave me important new information about the project.
We're perfectly within our rights to express how it makes us feel for it to be brought up, especially with the history we've had around it. It's caused us a lot of grief and we'd just like for it to stop being shoved in our face. That's all. If it was brought up by someone totally unique (not repeated by the same person as before, who we've already answered) then I would have had a different, more tactful response.
I really don't think it's fair for you to make a judgement on me or the project from an interaction like this. At least judge the project on its technical merits. I've been very transparent here. But I can't stop you from having your thoughts. It is what it is.
> being asked to repeat ourselves again is insulting to us.
> we'd just like for it to stop being shoved in our face.
This is the comment you are referring to:
> There still remains this simple to reproduce bug where the page doesn't load of you use the full domain name of a site.
They aren’t asking you to repeat yourself. They aren’t shoving it in your face. This is an open discussion thread with many participants. They weren’t talking to you directly. This is information anybody here can find interesting and relevant. I did.
> I really don't think it's fair for you to make a judgement on me or the project from an interaction like this. At least judge the project on its technical merits.
How you are reacting to this is far more important to me than the original bug.
Remember when 37signals suffered data loss because they were using GET requests to delete things? When people pointed out they had a bug, they were offended and blamed GWA. What happened next? The same thing happened all over again, users suffered more data loss.
Or how about when Naomi Wu reported a problem with Signal, where the common use case of third-party keyboards for Chinese people was rendering all of their security worthless? They dismissed that as somebody with a grudge and ignored her for a year. What happened next? People found out that Chinese keyboards were compromised; she was 100% right, and Signal users were in danger.
I’ve seen what happens when people have this attitude towards inconvenient people reporting inconvenient bugs. It’s a danger to users, and you are making Caddy seem dangerous with this attitude. I was a happy user of Caddy right up until this thread, and even halfway down this thread – even after reading the mention of the bug – but your reaction has flipped that to the opposite because I can’t trust that there aren’t more bugs you are handling this way.
This is being blown out of proportion. You're discounting an entire project and your experience of the software over a person expressing exasperation over an inconsequential feature (not a bug) that even the author of curl had his run through and frustration. The request was not dismissed, rather it was discussed at length on our issue tracker. The OP knows it was discussed at length because they linked to the discussion thread in the earlier times they brought this up. Moreover, the way they presented it this time is snide, agree or not. To quote Matt's statement of the project being "stable and mature" just to say "except you didn't implement my niche feature" (yes, editorialized) is not criticism nor a feature request. It's veiled instigation hiding behind plausible deniability.
Anyways, on the feature request, Caddy is not the only software who disagrees with it being valid, and curl had their back-and-forth on it. There's no legitimate bug being dismissed, and you can go through the issue tracker to audit it. Equating this discussion with 37signals or Signal is false equivalence.
Disclaimer: Caddy maintainer
> a person expressing exasperation
They accused them of a grudge, an attack, slander, and shoving it in their face. For something as mild as this:
> There still remains this simple to reproduce bug where the page doesn't load of you use the full domain name of a site.
That’s a long way beyond exasperation, that’s a massive overreaction.
It's a repeat complaint from the same person who admits bringing it up before. The way they framed their complaint is, again, snide.
> That’s a long way beyond exasperation, that’s a massive overreaction.
Your reaction to Francis is _the_ overreaction. Francis simply said to OP to put their money where their mouth is. The "slander" comment comes later as a general statement on why this subject has become annoying.
Stop being hung up on Francis' response. The niche feature was discussed at length multiple times. You're welcome to search the web for all the conversations we had on the subject. Caddy has been around for 11 years. We've seen this subject more than you've seen it brought up. Again, OP referenced the discussion on the issue tracker in one of the earlier times they brought it up. They _admit_ it's niche. What's the point of continuously bringing it up?
> It's a repeat complaint from the same person who admits bringing it up before.
This is what you’re referring to, right?
> > I think it's unfair to say that I post this every time when I've only mentioned it twice before, with the previous time being 2 years ago.
> Last year: https://news.ycombinator.com/item?id=39474419 and you also said "I have only brought this up once before on HN and it was over 2 years ago." in that same thread.
Okay, so the last time was 18 months ago not two years. But do you really think that mentioning it three times in 3.5 years can fairly be described as a grudge?
> Stop being hung up on Francis' response.
This is the only thing that matters to me in this thread. The bug itself is not that interesting. It’s a big deal to me that your team seems to take even the mildest mention of a bug as some kind of harassment. I’ve seen that kind of attitude before, and it’s dangerous.
Yes calling it a grudge is kneejerk, but no I won't apologize for it because of how intensely frustrating the prior discussions (and today's, no help to you) were to deal with (take today's, multiply it by two for the intensity, then multiply it by ten for the amount of times it happened). You aren't me, you don't know what I've experienced and you don't know all the details, so please stop making assumptions.
It's the fact they bring it up again when we've made it clear our stance is the problem, not so much the actual words in today's post. It's also off-topic (not relating to project maintainership) and it's on a post I submitted myself to HN.
I know you've already made up your mind, but look at our track record of answering support questions on the forums and tickets on GitHub, and you'll see that the picture you've formed in your mind from this thread is not accurate.
Those comparisons are very straw-man and I won't entertain them. As I've already said, IMO there's more risk in introducing a new security bug in trying to fix this issue than there is leaving it as-is (failing fast and hard).
> It's the fact they bring it up again when we've made it clear our stance is the problem
You are still locked into this idea that the sole purpose of bringing it up is for your response. This is an open conversation, not a dialogue between only you and them. It doesn’t matter if you have made your stance clear, them bringing it up gives other people a chance to hear about it and discuss it.
> I know you've already made up your mind, but look at our track record of answering support questions on the forums and tickets on GitHub, and you'll see that the picture you've formed in your mind from this thread is not accurate.
To be clear: my mind was made up that Caddy was a good, reliable choice, and it was your behaviour in this thread that changed my mind, it wasn’t my imagination.
> IMO there's more risk in introducing a new security bug in trying to fix this issue than there is leaving it as-is (failing fast and hard).
I believe that, but I also believe your attitude is a bigger threat to security than either.
And you're still locked into this idea that you'll convince me that I shouldn't care, when I've expressed how it makes me feel due to the history. Can you respect that there are topics I'd just like not to be reminded of in a certain way? If it was brought up in a _constructive_ way, I would accept it (i.e. offering help or a solution via a PR with tests). If it was brought up by someone who I didn't specifically interact with negatively on this topic before, I would accept it.
> I believe that, but I also believe your attitude is a bigger threat to security than either.
I can't change your belief, nor do I care to, but I think that's absurd. Show me an actual security threat relating to this and I will address it. But this problem as stated is not one.
> I can't change your belief, nor do I care to
You keep saying that, but you did change my belief! My opinion is not immutable, I listen to what people say, and that is the reason we have ended up here. Because I listened to you and you convinced me to change my mind about Caddy.
> Show me an actual security threat relating to this and I will address it. But this problem as stated is not one.
“This problem” that I’m concerned with is your attitude not the FQDN bug, and I already gave the Signal example. When you start perceiving people reporting bugs as attacks and grudges, it makes it dangerously easy to dismiss real problems.
If that person found another problem with Caddy, I think they are less likely to report it to you because of this. If they did report it, I would think you are very likely to dismiss it because of who they are, not the contents of the bug report. This is a serious problem for my trust in Caddy.
I thought I was clear enough about this already, but clearly not: I encourage anyone who believes there's a bug with Caddy to report it to us on GitHub, where bug reports belong, where we can have focused discussion about it and see it to its natural conclusion. I do not discriminate bug reports based on who makes it.
An HN thread is not the place to report a bug. Nor do I think it's fair to form opinions about project maintenance (which doesn't happen on HN) based on comments in HN.
> If that person found another problem with Caddy, I think they are less likely to report it to you because of this.
Given they're aware of previous discussion and the stance on the feature request, I don't think they're deterred by the discussion here. Your addition of fuel to fire here is the very thing that's not helping.
> If they did report it, I would think you are very likely to dismiss it because of who they are, not the contents of the bug report.
That's a huge assumption on your behalf.
[dead]
People are allowed to crticize a project whether or not they want to fix it. It was a mild, brief mention of one issue. Accurate, too, so not slander.
You seem to think there is a conspiracy against Caddy. That seems doubtful. But I could see disproportionate defensiveness like what is on display here causing some people to not be fans.
Two people don’t make a conspiracy. And honestly, the tone came off as pretty snide. Quoting part of the post just to twist it into their own point was clearly deliberate.
I've worked in a technical support forum with usually great guys, but what happened there was that specific complaints and specific users became designated the enemy of the group, by the group. Everything in contact with the specific issues or the specific users became twisted beyond recognition, and the group reacted to it always with aggressiveness. The "problem users" usually left after some time, then the group magically choose the next victim.
From the outside, such a group mechanism is happening here. Your reaction to the issue being brought up is not rational, and from the outside not understandable. Even if it was brought up 18 month before in the same way. And no, the curl post does not match your hostility. And no, the tone did not came off as "pretty snide", even if tribal voting pattern greys out your opposition anyway.
Please reconsider your approach here. If the issue is not fixable in caddy (though Apache seems to handle it fine?) maybe formulate a standard response that says something like "sorry, this is complicated, see the curl explication here" and leave it at that. Have an action plan that recognizes group dynamics and the burnout symptoms existing in the project, as mentioned in the article.
Your loss, caddy is fantastic