> Very bizarre, never seen that before.

For my own stuff that's not meant for a wider audience, I sometimes use mTLS in front of my apps, alongside self-signed certs (my own CA) that shouldn't show up in certificate transparency logs.

This site also seems to be requesting a certificate from the user. Normally you probably don't want that for public facing resources.

Same on Firefox

Here it attempts to read my personal certificate that sits in the browser that I use for filling my taxes and do government stuff, suspicious indeed.

Same on Zen

Same on Arc

Agree on lack of ACME but the codebase is far cleaner than nginx. In theory it'd be easier to audit?

Same thoughts. If I need more performant caddy alternative I'm going to use nginx at least it has some extras.

Yes, I agree it would be very nice to have a way to integrate ACME into zeroserve. I'm not sure if zeroserve's plugin system might allow one to add a plugin to support it?

Why? It's one of the most optimized HTTP servers ever. Anything that claims beating nginx in benchmarks should be treated with high suspicion. I think these zeroserve numbers are likely accurate but it doesn't have the features and module ecosystem of nginx so the margins aren't worth it for me.

I mean, nginx dang well should? This is just an incredibly synthetic http(s)/1.1 test for what its worth.

Like you totally could turn off garbage collection for caddy especially since this is only testing incredibly short single response queries that would never need GC. Shockingly you would actually get better performance than either nginx or zeroserve, but like the uselessness of this benchmark it'd mean nothing to the real world usage of these web servers.

zeroserve doesn't use the Linux kernel's eBPF runtime to run the eBPF it uses, so the constraints of the Linux kernel's eBPF runtime (chosen because of how the Linux kernel thinks about protecting the Linux kernel from user space) don't apply to zeroserve (or other tools that use the eBPF instruction set but don't use the Linux kernel's particular implementation)

For most apps the backend is slower than the proxy by a wide margin, so Caddy is nowhere near the bottleneck. Where it flips is high connection churn, since TLS handshakes are the expensive part and a flood of short lived connections without session resumption burns proxy CPU well before steady state proxying does. Very high RPS of tiny responses is the other case, where allocation and header parsing start to show.

Isn't there a chicken and egg problem where projects need to start with 0 track record? Nginx had zero track record at one point as well

Never mind cooldowns for dependencies, we need cooldowns for these adhd vibe projects.

Why does jit compilation here scare you? eBPF has had a ton of research on how to limit its resource usage and how to sandbox it.

> The idea of jit compilation of a web server in a small project is pretty terrifying to me. The attack surface here is enormous.

Does Spring Boot terrify you, then? Or Lua scripts in nginx? Or PHP? All of these use JIT compilation to run code that handles web requests.

Attack surface is a property of the JIT implementation, not of JIT itself. And eBPF is specifically designed to be very simple to implement and audit.

Except CDNs, where it is.