mholt

We definitely couldn’t have done it without the community rallying around free encryption and let’s encrypt.

> has no inherent benefit when running a project in production professionally

Tell that to Stripe and Framer and numerous other businesses using it very seriously and very much professionally! ;)

Thousands of Caddy users beg to differ -- nginx won't scale HTTPS automation as well as Caddy can.

That’s awesome! Thank you for sharing that with the community.

Caddy does (some of) that too actually. It has a live config API and support for clusters and synchronized configs and TLS cert management. It can also get the proxy upstreams dynamically at request-time through various modules. Some of the biggest deployments program/automate Caddy configs using APIs and multi-region infrastructure.

But where Envoy shines, it really shines.

Honestly, this has the potential to change the World Wide Web (I use that term very deliberately, given that PHP powers the vast majority of the Internet globally, including some of the biggest sites). This could be as huge of a change as when single core processors went multi-core. It is not uncommon to nearly double your site's performance and halve your work as a developer/devops person.

(Dividing line count by 2) It looks like we currently rely on about 322 direct or transitive dependencies. It's worth noting many of those are test-only dependencies.

A lot of the /x/ packages are repeated, just different versions; and I believe -- if my understanding is right -- a lot of these are only used for checksum verification, not necessarily a manifest of what is compiled into the binary.

But, the point remains, dependencies can bloat quickly, which is why we went with such a modular architecture for Caddy 2.

I was one of the first to doubt ARI and thoroughly grilled it on the IETF mailing list: https://mailarchive.ietf.org/arch/msg/acme/AeJ3zJKcBF-ZUhQXJ...

Now I'm warming up to it. But I still think I would have done it differently... ARI is essentially a "hint" to clients, but at the same time CAs can provide benefits (e.g. rate limit exemptions) if abiding by ARI windows. It feels weird to have scheduling split between the CA and the client. I would have liked a solution that either keeps the scheduling authority with the client, or transfers it to the CA, rather than straddling both. (I think my ideal scenario would be to have a single endpoint that returns a list of all certificates on the account that should be renewed presently. That way clients just have to poll it and renew any certs on that list. It would be much simpler than what I ended up implementing.)

I am not actually concerned too much with ARI with respect to revocation or hackers or government coercion. Mainly complexity.

Anyway... I could probably talk about the pros and cons of ARI for a while. It is a net good, I think, and it does solve a problem (mostly a problem CAs have, and it kind of puts the burden on clients). I just want the ACME/TLS ecosystem to settle down a little now. :)

We could improve that for sure. I am hoping to redo the website docs later this year... and will try to include some information about our development and release process.

Basically we try to put the bigger changes in the "minor" version bump (because bumping the major version introduces a lot of friction in the Go ecosystem) and encourage people to read release notes. We are open to suggestions though!

I will make sure our CI maintainers see this comment! They have poured much effort into making our release process smooth and digestible.

Hey, good question!

Semver is great for libraries. Caddy is a project which has so many dimensions of "surface area" that it's hard to boil down the implications of changes into a single decimal-separated number. Presumably this is why a lot of larger projects use year-month versioning or just bump the major version every release. I'm actually considering doing the latter, except ... Go modules are very opinionated about major version bumps because it was designed with libraries, not commands (main funcs) in mind... and bumping the major version each release would be also be a major inconvenience to dozens of plugin authors.

Caddy has a Go API, a configuration surface (two built-in: JSON and Caddyfile); a config API; HTTP, TLS, TCP, and UDP behavior; a command-line interface; etc... the list goes on and on in ways that can break a deployment. Which of those does the one and only semver version apply to? Go has opinionated tooling around semver for the Go package stuff, so we kind of have to cater to that, but end users don't really care about that. We could split the project into multiple smaller sub-projects, each with their own versions, but then it gets confusing and tedious to build and maintain. It's also inconvenient for people to contribute to that. And we'd have to ship Caddy with several versions, one for each "surface area dimension."

We've settled on mediocrity with our current version scheming which I admit is not my favorite, but I haven't really found anything better yet. Year-month versions are nice except that it implies either a regular release cadence (which we don't have) or that a larger span between two releases is more significant than more frequent releases (maybe true, but maybe not); it doesn't really tell you anything about the build... just approximately when it was made, but not even exactly when it was made (a month is a big window!) - I guess if you do multiple releases per month you just tack another number on the end? Maybe it should just be a timestamp. Or we could invent an N-dimension decimal number or some sort of string that has to be split and parsed...

Anyway. We do try to be gentle with breaking changes. Most of these have been documented as deprecated for years as well as printing warnings in logs. But we try to minimize the number of these, for sure.

Do any of Photostructure, Photoprism, Ente, or Immich fit the bill?

(Edit: I guess Ente is online)

Ever since 2016 I actually do a named import for "math/rand" now by calling it "mathrand" or "weakrand" just to be sure I don't accidentally use it for anything secure.

Go keeps getting better. Thanks for your hard work!

How do you mean? Many of our users do this with no issues.

We're revamping the Caddy docs this year.

Yeah, Caddy v1 had a forwardproxy plugin that finally got updated for v2: https://github.com/caddyserver/forwardproxy/

Funny you say that because we don’t have nearly any examples in the Caddy docs. We’re working on improving them later this year.

Caddy is actually used as a reverse proxy more than a static file server. It's equally excellent and proficient as both! Caddy's functionality is comparable to nginx, apache httpd, and haproxy.

Caddy can absolutely do both of those things.

- https://caddyserver.com/docs/modules/http.reverse_proxy.upst...

- https://github.com/mholt/caddy-l4

That is absolutely not the case. Caddy config reloads are graceful and lightweight. I have no idea why this person is stopping their server instead of reloading the config.

Safari IS often behind on things. It's the ONLY major browser that doesn't support 'overflow-anchor: auto' even though that's been the default in all other browsers for years now. https://caniuse.com/css-overflow-anchor

Their TP finally implements it, but years late.

No, look at the associated unit test: https://github.com/caddyserver/caddy/blob/c6eb186064091c79f4...

If that test fails we could serve PHP source code instead of having it be evaluated, a potential security flaw.

I would just like to take this opportunity to complain about Windows file paths and especially parsing them in cross-platform software like a web server that joins request paths that always use / to Windows filepath roots that may or may not use \. I also hate that Windows paths are limited to 260 characters !?

Seriously, in Caddy, I have some of the most bizarre special code paths for Windows. For example: https://github.com/caddyserver/caddy/blob/c6eb186064091c79f4...

Can someone who understands and appreciates the way Windows does files please help me appreciate it too?

This article did not help me have gratitude for Windows: https://www.fileside.app/blog/2023-03-17_windows-file-paths/

> we realise that we can construct an almost unlimited number of different path strings that all refer to the same directory.

:o

The EFF themselves recently explored the question whether Certbot should just be replaced with servers like Caddy. https://www.eff.org/es/deeplinks/2024/03/should-caddy-and-tr...

I was going to disagree with you but then I noticed your username :P

Then I was going to agree with you. But that didn't seem rational either. O.o

That most likely just means they are opening the door to discontinuing them more easily in the future.

> I've been buying digital music from one of the reasonably good online sources of it (the one that recently got acquired, again, making people nervous about its longer term future).

Which store is being referred to here?

This site makes me glad to have a 49" wide monitor. (Click around to the various projections: maps, statistics, etc. Very interesting!)

Aragorn II did.

This article doesn't go into depth about capturing the profile to identify the leak, so if you want more instruction on one way to do that, I wrote an article recently called Profiling Caddy, which is geared toward Caddy but really works for any Go programs: https://caddyserver.com/docs/profiling