Thanks for Caddy, Matt! Some of us on the team have been using Caddy for years, for many of our projects. Because it's so simple, sufficiently high performance, and has lots of nice features.
The on-demand TLS certificates with an "ask" endpoint is especially useful for the PDS use-case. Because there's generally a wildcard DNS name that is used to give each new user a domain handle (@alice.example.com) but we don't want to be vulnerable to a TLS certificate DoS/rate limit situation.
That is a bit unfair, as it is intentionally not doing so. You may disagree with it, sure, but as it stands I think your comment implies oversight or immaturity, which is evidently not the case reading the discussion on the issue you linked.
>That is a bit unfair, as it is intentionally not doing so.
That doesn't change my point. I am pointing out a an easy pitfall Caddy users can fall in since it is not automatically handled for them as it is with other server software, nor is it pointed out in the documentation fkr Caddy. Simple server software would avoid these pitfalls automatically for users. So while it now be simple to get https working, properly configuring the server is now more complex to get right.
An intentional pitfall doesn't mean it isn't a pitfall.
I have only brought this up once before on HN and it was over 2 years ago. Not adopting a new project because it is missing something niche is an extremely common reason why people stick with tried and true, mature software. I do not see anything wrong with pointing out niche issues because to some people these issues are important. Because it's broken out of the box it is allowing people who aren't aware of this problem to continue to setup broken sites. Even caddyserver.com. is broken.
Curious. What is the use case here? I’ve spent tens of thousands of hours of my life on the Internet and a lot of that as a sysadm and I’ve not once heard of people accessing or linking to sites this way.
Personally, I just want to properly handle this edge case and it would bother me if my sites didn't handle it correctly. There are advantages for using FQDNs since they are not ambiguous there are extra optimizations that can be done. I don't want my sites to be problematic for people who want to use them so I make sure my sites properly handle them. Usually handling FQDNs is easy as it just works out if the box on most server software.
The on-demand TLS certificates with an "ask" endpoint is especially useful for the PDS use-case. Because there's generally a wildcard DNS name that is used to give each new user a domain handle (@alice.example.com) but we don't want to be vulnerable to a TLS certificate DoS/rate limit situation.