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!
This also has an include directive, so there’s more we’re not seeing. And what’s the SSLLabs score for that setup’s TLS?
But it’s not only the config that makes Caddy nice. I think that’s a good example of the kind of care and consideration that goes into Caddy’s development, though.
That "except" is doing a lot of lifting, in my opinion. Automatic Let's Encrypt is a big part of why I reach for Caddy. Install, run, done. No cert management headaches. It felt like magic the first time I used it, and now that I think of it, it still does.
Right, in the nginx example above, someone has setup a secondary tool to provide certs at the location referenced, and is also handling renewal of them.
Also, if I want to add another domain that should be accepted and reverse proxied to my application, in Caddy I just do this:
Suddenly not only does my Wordpress site respond on example.com, but also wp.example.com, and caddyfreakingrules.example.com, Caddy will fetch and automatically rotate certs for all three domains, and Caddy will auto-redirect from http to https on all three domains. (Does the ngnix example actually do that?)
Another thing, does nginx with the above configuration automatically load new certs if the ones that were there when the process spawned have since expired? Because not only does Caddy automatically renew the certs, it is handled transparently and there's zero downtime (provided nothing changes about the DNS pointers of course).
Caddy is freaking awesome!
Bonus, if this were your Caddyfile (the entire thing, this is all that's needed!):
{
admin off
auto_https prefer_wildcard
email hostmaster@example.com
cert_issuer acme {
dir https://acme-v02.api.letsencrypt.org/directory
resolvers 1.1.1.1 1.0.0.1
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
ocsp_stapling off
}
example.com wp.example.com caddyfreakingrules.example.com {
root * /var/www/wordpress
php_fastcgi unix//run/php/php-version-fpm.sock
file_server
}
# This is simply to trigger generation of the wildcard cert without
# responding with the Wordpress application on all of the domains.
*.example.com {
respond "This is not the app you're looking for" 404
}
Then you'll disable the unauthenticated JSON API on localhost:2019 (which is a good security practice, this is my only gripe with Caddy, this API shouldn't be enabled by default), tell Caddy how to use the DNS-01 ACME resolver against Cloudflare (requires a plugin to Caddy, there are loads for many DNS providers), and then tell Caddy to use appropriate wildcard certs if it has generated them (which for *.example.com it will have).
The result of which is that Caddy will only generate one cert for the above 3 sites, and Let's Encrypt won't leak the existance of the wp.example.com and caddyfreakingrules.example.com domains via certificate transparency.
It's also extremely nice as a reverse proxy. You get the certificate for free and defering authentication to a middleware is very easy. The community has some very good option for this like caddy-security.
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.
The main difference (as someone who is familiar with nginx and caddy, and whose Apache knowledge mostly comes from the era of "webapps are folders in your root with PHP files in them", so not very good) is that Nginx tends to be a very hands-off webserver. It doesn't do anything for you that the config files don't specify it should do. Of the three main ways to serve web content out there (static, CGI-esque aka PHP or a reverse proxy), nginx only really has a near config free experience (as in, your distro probably shipped a default config to make this work with zero effort) for serving static files - you just make a server block, a location block and point the root to the folder you want to serve. Setting up PHP or reverse proxies requires a lot more manual work; if you want X-Forwarded-* headers, you're gonna have to set those up for example.
Similarly, nginx isn't going to be the one picking your SSL config out of the box; it's a bunch of arcane flags and settings (if you're not intimately familiar with SSL anyways) that you look up once how to get the SSLabs A+ score and then you put it in a reusable snippet to not have to think about that stuff ever again for future domains. If you want ACME certificates, you're gonna have to tell it to do that (nginx recently got a module for this I think, which kinda makes it equal in this sense to caddy's automatic LE cert generation) or where to find the certificates.
Caddy automates a lot of this sort of thing; the result is smoother/cleaner config files (it's hard to deny that reverse_proxy is shorter than the several dozens of config lines you'd use for nginx) but you also need to be aware of what Caddy does by default and the assumption that what the Caddy developers think should be the default will also always be what you want, unless you want to poke at manual overrides (in which case it's pretty much nginx again.) It can also do a few common variants on static site hosting, like automatically pulling a git repo, running a page generator on it and serving the resulting folder, which nginx just straight up doesn't do afaik.
In practice, I found Caddy works well on development/toy machines where there's no real expectations for having to think about prod and "not having to spend an hour reconfiguring your setup" when you start a project is beneficial and it's easy to swap things like ports around. Nginx works better on production machines because you basically set it up once and then can safely never have to think about it again, while still allowing you explicitly see why it's (not) doing what you want later down the line.
Traefik I legitimately couldn't see a reason to use however. It's config syntax is atrocious and looking it up online tells me it's mainly popular with non-technical homelab people because it can serve a web UI to manage your reverse proxies in. I guess that's a desirable feature for some?
There were a few years where Apache was playing catch-up to nginx, but they were short-lived, and you would be well-served by re-examining it, as I am always reading these threads shaking my head at how much people praise these random tools for doing X or Y or whatever, and Apache just handles it all (including ACME, since 2017), with maybe a few extra lines of configuration, while being so insanely extensible that basic things like how it handles sockets or what protocol it speaks are modules. It just hits a really nice sweet spot between all of these other tools.
I might actually do that; like I said, I mostly just moved on to nginx eventually because it happened to fit how I wanted to configure a server. It was mostly me comparing nginx to caddy.
One thing I did like about Apache back in the day was that it made it really easy to give per served web folder configuration. Nowadays I just toss stuff on a subdomain (cuz there's little reason not to), but if you only have one hostname to put things on (ie. a homelab thatt you can only access by local IP address), that's obviously not an option. .htaccess files were pretty neat for doing that.
Nginx can't really do that as easily, you have to start futzing with different location blocks and it kinda gets messy quickly.
On a not-so-relevant note, I do think Apache has probably the nicest "dirlist" out of all of them. Nginx's is really ugly and Caddy's feels too overdesigned.
You can easily customize Caddy's browse template to your liking. It's just a text file, you can take the default and modify it, or write your own from scratch if you like. See https://caddyserver.com/docs/caddyfile/directives/file_serve... Some users have posted theirs on the forums as well if you need more inspiration.
I have an old-school sysadmin background, and was responsible for some seriously large Apache installations in the 2000s. I stuck with it during the dark days of the introduction of mpm_worker, and could probably still churn out mod_rewrite rules in my sleep.
Would I use it for a new service today? No.
Not because the configuration itself is complex (as I say, I've been working with it for decades), but because managing the config is complex.
You end up using custom templating systems, testing the new config oob, and then sending signals to the daemon. There's a huge pile of scripting needed to manage all of this in even the most basic way, let alone integrate it with a service mesh or orchestration system.
Even the ASF will push you towards ATS or Dubbo or APISIX rather than old-school Apache Server.
Caddy will get you up and running in seconds, whereas forcing Apache's square peg into the modern environment's round hole is going eat weeks for very little benefit.
I could've written much the same. I used Apache from the late nineties until around 2010, and I can manage it. I just don't want to anymore. It's not worth the pain.
Ok, that's fair: it is always quite disappointing when a project lies about its status (and if I ever get a chance to complain directly about that, I probably will)... but, at least it used to be accurate (and likely was until very recently)? A lot of projects (I see this often with terminal apps) say stuff like "the fastest X", only, when you do a benchmark, they aren't even fast in an absolute sense, much less in a relative sense to other projects (and I believe I remember this being the case for nginx for a while vs. Apache with mpm_event).
This really hits home, since I’m working on trying to achieve similar spread of maintainership on pyinfra[1] (which I note is much less popular than Caddy). But all the same issues and out of control GH notifications. Hope this goes well, Caddy is awesome software!
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.
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)
My comment was not an attack on Matt, but against the idea of forcing[1] users to pay for (/donate to) in order to use libre software. Organic donations and sponsorships are great!
1. This may have been a misread on my part, on second read, gp's comment says nothing about mandatory payment. The reason I'm wary of mandatory payments is that you'd have to quantify who deserves what, and expend more time on the administration - likey setting up a foundation or company, or which not every F/OSS project needs. Again, I'm speaking generally - a Caddy Foundation, or Caddy Inc. may be appropriate. "Open source project" is a very broad term, ranging in size from leftpad to the Linux kernel, and the needs will be different for each.
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.
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.
Yes, for Caddy v0, which is no longer relevant because Caddy v2 was a rewrite from the ground up. No issues have been opened by anyone who cares about this since Caddy v2 was released over 5 years ago.
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.
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.
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.
I wish my biggest problem was that two people mentioned (correctly) a minor flaw I have, once every two years.
You’ve explained why you won’t fix it (seems that you don’t feel you’ve got sufficient coverage to be confident to do so, or that it’s not possible to cover this type of change) so just put an faq up about it and do not take it personally. You cannot expect zero criticism.
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.
I say this with some trepidation. I certainly don't want to inflame this.
First, never used Caddy. I have no dog in this fight. I do manage a (closed source) project (which is decades old).
After reading this entire thread and all replies in all branches (I didn't vote on any of the comments), I think it would have been better for you not to reply at all. It would have done less damage to you (the negative emotions it brought out, the perception of others) and no one would remember that top-level comment. It would have been at the bottom of the page, an insignificant utterance. You elevated it, by protesting too much (I won't quote that famous line, but you get the idea).
And I must say you reminded me of my younger self, in the way you wouldn't let go of the issue and wouldn't let others have the last word. I've learned that this behavior is definitely self destructive and unproductive. The trigger was something that lived in me. It was never, I learned, about them. We choose how we respond. I've found one thing to work for me:
When an online discussion makes me emotional, I write a response in a text editor (not in the place where the comment is) and I let it sit for a few hours. Then, I do something completely different. I almost never post that comment, when I return to it, but I sometimes post something much softer. Mostly, I remove all emotion from the comment. Emotions are triggers for others, after all.
Why did I write so many words on this seemingly trivial online dispute? I hope I can help in some way, because I saw myself in your comments. Take them for what they are, me trying to help.
> 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 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.
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!
This also has an include directive, so there’s more we’re not seeing. And what’s the SSLLabs score for that setup’s TLS?
But it’s not only the config that makes Caddy nice. I think that’s a good example of the kind of care and consideration that goes into Caddy’s development, though.
> except for the explicit cert
That "except" is doing a lot of lifting, in my opinion. Automatic Let's Encrypt is a big part of why I reach for Caddy. Install, run, done. No cert management headaches. It felt like magic the first time I used it, and now that I think of it, it still does.
Right, in the nginx example above, someone has setup a secondary tool to provide certs at the location referenced, and is also handling renewal of them.
Also, if I want to add another domain that should be accepted and reverse proxied to my application, in Caddy I just do this:
Suddenly not only does my Wordpress site respond on example.com, but also wp.example.com, and caddyfreakingrules.example.com, Caddy will fetch and automatically rotate certs for all three domains, and Caddy will auto-redirect from http to https on all three domains. (Does the ngnix example actually do that?)Another thing, does nginx with the above configuration automatically load new certs if the ones that were there when the process spawned have since expired? Because not only does Caddy automatically renew the certs, it is handled transparently and there's zero downtime (provided nothing changes about the DNS pointers of course).
Caddy is freaking awesome!
Bonus, if this were your Caddyfile (the entire thing, this is all that's needed!):
Then you'll disable the unauthenticated JSON API on localhost:2019 (which is a good security practice, this is my only gripe with Caddy, this API shouldn't be enabled by default), tell Caddy how to use the DNS-01 ACME resolver against Cloudflare (requires a plugin to Caddy, there are loads for many DNS providers), and then tell Caddy to use appropriate wildcard certs if it has generated them (which for *.example.com it will have).The result of which is that Caddy will only generate one cert for the above 3 sites, and Let's Encrypt won't leak the existance of the wp.example.com and caddyfreakingrules.example.com domains via certificate transparency.
It's also extremely nice as a reverse proxy. You get the certificate for free and defering authentication to a middleware is very easy. The community has some very good option for this like caddy-security.
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.
The main difference (as someone who is familiar with nginx and caddy, and whose Apache knowledge mostly comes from the era of "webapps are folders in your root with PHP files in them", so not very good) is that Nginx tends to be a very hands-off webserver. It doesn't do anything for you that the config files don't specify it should do. Of the three main ways to serve web content out there (static, CGI-esque aka PHP or a reverse proxy), nginx only really has a near config free experience (as in, your distro probably shipped a default config to make this work with zero effort) for serving static files - you just make a server block, a location block and point the root to the folder you want to serve. Setting up PHP or reverse proxies requires a lot more manual work; if you want X-Forwarded-* headers, you're gonna have to set those up for example.
Similarly, nginx isn't going to be the one picking your SSL config out of the box; it's a bunch of arcane flags and settings (if you're not intimately familiar with SSL anyways) that you look up once how to get the SSLabs A+ score and then you put it in a reusable snippet to not have to think about that stuff ever again for future domains. If you want ACME certificates, you're gonna have to tell it to do that (nginx recently got a module for this I think, which kinda makes it equal in this sense to caddy's automatic LE cert generation) or where to find the certificates.
Caddy automates a lot of this sort of thing; the result is smoother/cleaner config files (it's hard to deny that reverse_proxy is shorter than the several dozens of config lines you'd use for nginx) but you also need to be aware of what Caddy does by default and the assumption that what the Caddy developers think should be the default will also always be what you want, unless you want to poke at manual overrides (in which case it's pretty much nginx again.) It can also do a few common variants on static site hosting, like automatically pulling a git repo, running a page generator on it and serving the resulting folder, which nginx just straight up doesn't do afaik.
In practice, I found Caddy works well on development/toy machines where there's no real expectations for having to think about prod and "not having to spend an hour reconfiguring your setup" when you start a project is beneficial and it's easy to swap things like ports around. Nginx works better on production machines because you basically set it up once and then can safely never have to think about it again, while still allowing you explicitly see why it's (not) doing what you want later down the line.
Traefik I legitimately couldn't see a reason to use however. It's config syntax is atrocious and looking it up online tells me it's mainly popular with non-technical homelab people because it can serve a web UI to manage your reverse proxies in. I guess that's a desirable feature for some?
There were a few years where Apache was playing catch-up to nginx, but they were short-lived, and you would be well-served by re-examining it, as I am always reading these threads shaking my head at how much people praise these random tools for doing X or Y or whatever, and Apache just handles it all (including ACME, since 2017), with maybe a few extra lines of configuration, while being so insanely extensible that basic things like how it handles sockets or what protocol it speaks are modules. It just hits a really nice sweet spot between all of these other tools.
I might actually do that; like I said, I mostly just moved on to nginx eventually because it happened to fit how I wanted to configure a server. It was mostly me comparing nginx to caddy.
One thing I did like about Apache back in the day was that it made it really easy to give per served web folder configuration. Nowadays I just toss stuff on a subdomain (cuz there's little reason not to), but if you only have one hostname to put things on (ie. a homelab thatt you can only access by local IP address), that's obviously not an option. .htaccess files were pretty neat for doing that.
Nginx can't really do that as easily, you have to start futzing with different location blocks and it kinda gets messy quickly.
On a not-so-relevant note, I do think Apache has probably the nicest "dirlist" out of all of them. Nginx's is really ugly and Caddy's feels too overdesigned.
You can easily customize Caddy's browse template to your liking. It's just a text file, you can take the default and modify it, or write your own from scratch if you like. See https://caddyserver.com/docs/caddyfile/directives/file_serve... Some users have posted theirs on the forums as well if you need more inspiration.
I have an old-school sysadmin background, and was responsible for some seriously large Apache installations in the 2000s. I stuck with it during the dark days of the introduction of mpm_worker, and could probably still churn out mod_rewrite rules in my sleep.
Would I use it for a new service today? No.
Not because the configuration itself is complex (as I say, I've been working with it for decades), but because managing the config is complex.
You end up using custom templating systems, testing the new config oob, and then sending signals to the daemon. There's a huge pile of scripting needed to manage all of this in even the most basic way, let alone integrate it with a service mesh or orchestration system.
Even the ASF will push you towards ATS or Dubbo or APISIX rather than old-school Apache Server.
Caddy will get you up and running in seconds, whereas forcing Apache's square peg into the modern environment's round hole is going eat weeks for very little benefit.
I could've written much the same. I used Apache from the late nineties until around 2010, and I can manage it. I just don't want to anymore. It's not worth the pain.
As a side note, I see that Apache still describes it as "the most popular web server on the Internet", but that's probably not the case: https://w3techs.com/technologies/overview/web_server
To me, that has shades of XFree86 calling itself "the premier open source X11-based desktop infrastructure." Um...
Ok, that's fair: it is always quite disappointing when a project lies about its status (and if I ever get a chance to complain directly about that, I probably will)... but, at least it used to be accurate (and likely was until very recently)? A lot of projects (I see this often with terminal apps) say stuff like "the fastest X", only, when you do a benchmark, they aren't even fast in an absolute sense, much less in a relative sense to other projects (and I believe I remember this being the case for nginx for a while vs. Apache with mpm_event).
For me it's been 95% and 5%. Caddy is great!
community management is hard, good luck
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 :)
Well then.
Hopefully some Mikes have been involved in the project as well and picked up some stray well wishes.
Haha, hi Mike!
(He and I were coworkers for a time.)
This is too cute.
This really hits home, since I’m working on trying to achieve similar spread of maintainership on pyinfra[1] (which I note is much less popular than Caddy). But all the same issues and out of control GH notifications. Hope this goes well, Caddy is awesome software!
[1] https://github.com/pyinfra-dev/pyinfra
Caddy is excellent. Great on you, Matt for giving up some control.
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.
Thanks for everything you've done. Caddy is beautiful. I hope this helps you enjoy life more, as well as ultimately help caddy grow further.
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)
My comment was not an attack on Matt, but against the idea of forcing[1] users to pay for (/donate to) in order to use libre software. Organic donations and sponsorships are great!
1. This may have been a misread on my part, on second read, gp's comment says nothing about mandatory payment. The reason I'm wary of mandatory payments is that you'd have to quantify who deserves what, and expend more time on the administration - likey setting up a foundation or company, or which not every F/OSS project needs. Again, I'm speaking generally - a Caddy Foundation, or Caddy Inc. may be appropriate. "Open source project" is a very broad term, ranging in size from leftpad to the Linux kernel, and the needs will be different for each.
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.
I like Caddy. Good to see it evolve. Hope it works well
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.
Everyone I know has used Caddy by default for so long now that I'd describe Nginx as an alternative to Caddy, at this point.
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.
I want to use Caddy as an ingress or gateway in Kubernetes.
I have not configured lone servers in a long long time
>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./
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.
[dead]
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.
> we've never had any github issues opened about it in years, neither on our forums
Looks like https://github.com/caddyserver/caddy/issues/1632 to me?
Yes, for Caddy v0, which is no longer relevant because Caddy v2 was a rewrite from the ground up. No issues have been opened by anyone who cares about this since Caddy v2 was released over 5 years ago.
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.
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.
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.
I wish my biggest problem was that two people mentioned (correctly) a minor flaw I have, once every two years.
You’ve explained why you won’t fix it (seems that you don’t feel you’ve got sufficient coverage to be confident to do so, or that it’s not possible to cover this type of change) so just put an faq up about it and do not take it personally. You cannot expect zero criticism.
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.
I say this with some trepidation. I certainly don't want to inflame this.
First, never used Caddy. I have no dog in this fight. I do manage a (closed source) project (which is decades old).
After reading this entire thread and all replies in all branches (I didn't vote on any of the comments), I think it would have been better for you not to reply at all. It would have done less damage to you (the negative emotions it brought out, the perception of others) and no one would remember that top-level comment. It would have been at the bottom of the page, an insignificant utterance. You elevated it, by protesting too much (I won't quote that famous line, but you get the idea).
And I must say you reminded me of my younger self, in the way you wouldn't let go of the issue and wouldn't let others have the last word. I've learned that this behavior is definitely self destructive and unproductive. The trigger was something that lived in me. It was never, I learned, about them. We choose how we respond. I've found one thing to work for me:
When an online discussion makes me emotional, I write a response in a text editor (not in the place where the comment is) and I let it sit for a few hours. Then, I do something completely different. I almost never post that comment, when I return to it, but I sometimes post something much softer. Mostly, I remove all emotion from the comment. Emotions are triggers for others, after all.
Why did I write so many words on this seemingly trivial online dispute? I hope I can help in some way, because I saw myself in your comments. Take them for what they are, me trying to help.
> 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]
Your loss, caddy is fantastic
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.
[flagged]