I somewhat remember the Caddy team having a history of shady behavior: advertisements in headers, hostility towards contributors, telemetry you have to opt-out of. Has any of this changed or has it become worse?
The headers was one of the worst days of my life, believe me. I heard your feedback loud and clear and they were removed shortly thereafter... now about 3 years ago: https://caddy.community/t/the-realities-of-being-a-foss-main... The telemetry server was shut down months ago and v2 has no telemetry client. Although, the counts we gathered were informative. We learned a lot about MITM activity on the Internet, the hea…
Show HN: Caddy 2
31–40 of 247 posts
Re: Show HN: Caddy 2
#32The biggest feature in Caddy 2, from what I can tell, is the new HTTP config API, and I'd love to see a practical example of what could be done with that.
Re: Show HN: Caddy 2
#33I started using caddy v1 thanks to lightning-fast and simple TLS setup and extremely simple configuration in general, thanks to the excellent docs and handy plugins for common stuff like cors, rewrites and fastcgi. Shortly after upgrading to caddy v2, I switched to nginx, after spending way too much time trying to make sense of the new Caddyfile and docs (the thing I miss the most of the docs is the plugin list, alon…
I've already got the new build server mostly written -- should be way faster.
Re: Show HN: Caddy 2
#34Earlier quoted context omitted.
Some parameters might have one or two more words to type, but the growth in flexibility is enormous, and we felt it was worth the tradeoff. You can see a comparison here: https://caddyserver.com/docs/v2-upgrade#caddyfile We also think slightly more verbosity in the v2 Caddyfile is actually a good thing. Aside from more flexibility, it makes it a little clearer what's going on, and concerns are better separated. For e…
Thanks for the response! Looking forward to upgrade my stuff. Is there a reason why you decided to introduce an entirely new configuration method via JSON?
Basically, it is highly interoperable and allows us to build config adapters on top of it, so you don't have to use JSON if you really don't want to. Most people use the Caddyfile. You can use YAML or TOML or CUE if you prefer those. Or heck, you can use your nginx config: https://github.com/caddyserver/nginx-adapter
Re: Show HN: Caddy 2
#35Re: Show HN: Caddy 2
#36 echo "deb [trusted=yes] https://apt.fury.io/caddy/ /" | sudo tee -a /etc/apt/sources.list.d/caddy-fury.list
apt update && apt install caddyRe: Show HN: Caddy 2
#37Does Caddy request separate certificates for domains served through it, or is it handled using SANs?
CommonName has been deprecated for years, so all of Caddy's certificates (and all of Let's Encrypt's) are SAN certificates. Caddy manages single-SAN certs, in accordance with recommended best practices: https://docs.https.dev/acme-ops#use-one-name-per-certificate
(We learned from experience that single SAN scales better and is less prone to troubles. For example, Caddy sites were not affected by the recent Let's Encrypt revocation incident because it manages only single-SAN certificates. And frankly, that shouldn't matter since you don't have to manage them.)
Re: Show HN: Caddy 2
#38Re: Show HN: Caddy 2
#39Does Caddy request separate certificates for domains served through it, or is it handled using SANs?
Both, technically. CommonName has been deprecated for years, so all of Caddy's certificates (and all of Let's Encrypt's) are SAN certificates. Caddy manages single-SAN certs, in accordance with recommended best practices: https://docs.https.dev/acme-ops#use-one-name-per-certificate (We learned from experience that single SAN scales better and is less prone to troubles. For example, Caddy sites were not affected by th…
I was asking because right now my nginx/certbot setup requests a single certificate for all my domains, and I would like to have them separate.
(I'm sure you can do that with certbot, I just haven't tweaked my setup, yet)
Re: Show HN: Caddy 2
#40Earlier quoted context omitted.
The headers was one of the worst days of my life, believe me. I heard your feedback loud and clear and they were removed shortly thereafter... now about 3 years ago: https://caddy.community/t/the-realities-of-being-a-foss-main... The telemetry server was shut down months ago and v2 has no telemetry client. Although, the counts we gathered were informative. We learned a lot about MITM activity on the Internet, the hea…
Why did you do it? What have you sought to achieve with it? It's always a head scratcher for me why people building open source tools would put time and effort towards telemetry. Advertisments in HTTP headers? That's a new one. Advertise to whom, devs looking at a browser debug console?
We collected some good measurement data -- anonymous, technical, non-personal, etc -- but the terabytes added up and the academic community didn't seem particularly responsive to it in the end. The "opt-in" / "opt-out" depended on how you built/obtained Caddy, but essentially we made it a compile-time decision so that we could reduce biases from the data. By deciding on the download page whether telemetry was enabled, we could also know how representative the data actually was: otherwise it'd be meaningless.
We also wanted to know how widely Caddy was being used. Telemetry was mostly just counts of things, so that's how we know that Caddy has secured trillions of HTTPS requests and managed millions of certs. But it was expensive to run.
The "ads" in headers were intended to be a friendly nod to our sponsors who made it possible. It was a novel idea. I thought it was a good balance of non-intrusive and perfectly visible at the same time: developers who were peering into HTTP requests would see the headers and our sponsors would get some benign recognition from their target audience, while nobody else would see them. It also was supposed to encourage purchasing commercial licenses, which didn't have that header. The licenses were necessary to continue funding a desperately underfunded project.
Needless to say that didn't work out and the only reason the Caddy project didn't shut down entirely is because corporate sponsors (Ardan Labs and one other to be announced probably next week) believed in the project enough to pick it up.
So anyway, I also got college credit for implementing an Internet measurement system, which was really fun and interesting. And as mmalone said adjacently, open source projects really need to know what kind of usage they're getting. With no way to engage customers except at their voluntary discretion, it's impossible to know how to improve the project. Open source is, by definition, an open feedback loop. It only closes if users come back and provide information.
A lot of other major open source projects or free software ship telemetry, even on by default sometimes -- see Windows, Chrome, Ubuntu, Firefox, VS Code, macOS, and countless others. Yet nobody cares.
But having that information was critical in shaping the development of Caddy 2, FWIW.