[ptx]

Is there a good alternative to Apache and Nginx that's written in a memory-safe language and not full of security holes? I briefly looked at Jetty (written in Java) and Caddy (written in Go) but they seem to have a history of vulnerabilities of other types (e.g. shell injection in Jetty) so I'm not sure they would be any better.

[nobody42]

Memory safety is good, but does not protect from every threat. In this day and age infrastructure operators should familiarize themselves with proactive defenses, MAC: SElinux and AppArmor. It required much friction earlier, but there are more tools to ease the usage today.

https://presentations.nordisch.org/apparmor/

https://github.com/nobody43/apparmor-profiles/blob/master/ng...

https://github.com/nobody43/apparmor-suggest

Disclaimer: I'm the author of both repos.

[dgellow]

Any software used at the scale of Apache and nginx will have a history of vulnerabilities. The fact they both survived with their market share for so long is a good sign

[ptx]

Right, that's essentially what I'm thinking.

On the one hand Apache and Nginx are mature and proven but, being written in C, they will always suffer from memory-safety issues like this one and the recent Apache vulnerabilities.

On the other hand, the alternatives are perhaps not as mature and perhaps not implemented as securely as they could be, given that e.g. Caddy had multiple vulnerabilities in its request parsing this year and Jetty's shell injection vulnerability seems easily foreseeable and avoidable. Using a memory-safe language doesn't help much if you then (to take an unrelated but well-known example) implement arbitrary code execution as a feature in the logging library.

[GoblinSlayer]

LDAP feature can be removed from log4j, but buffers can't be removed from nginx. Technically, bounds checking can be implemented, but presumably nginx has no plans for it, because it's anathema.

[embedding-shape]

Caddy been a breeze to use, bit sucky model with "we have thousands of binaries depending on what combination of plugins you want" instead of a proper plugin system, but if you're building it from source, it's pretty nifty and simple anyways.

[eikenberry]

Recompiling with the features you want is a great model for a free software project. So much simpler to write and maintain compared to a plugin system that it really makes more sense in a lot of cases.

[seanw444]

Can often also be noticeably more performant.

[sharperguy]

I've switched to using traefik from caddy. For simple use cases it's a little more verbose in the configuration, but for more involved things like multiple load balancing backends, rewriting paths and headers and so on I've found it really good.

[pjmlp]

That is a consequence of static linking, and an abandoned plugin package that hasn't yet been removed due to backwards compatibility.

People keep forgetting that with static linking they are back to 1980's IPC for application extensions, or building from scratch every time they need to reconfigure the application.

[dboreham]

Go doesn't support runtime linking, which is why "no plugins" (even though Go docs claim it does, no it doesn't).

[vbernat]

nginx had this defect for a long time too!

[toast0]

Apache and I think Nginx have a huge list of features and stuff. Most alternate http servers limit the scope a lot, so you'd need to specify what features you're interested in.

But I haven't seen a whole lot of discussion of http servers in memory safe languages. The big three C-based servers: Apache, Nginx, and lighttpd are all pretty solid... I don't think there's a lot of people interested in giving that up for a new project just because of the language.

I'll also add that when you pick up most memory safe languages, you're also picking up their sometimes extensive runtime / virtual machine and all the accoutrements. A Java webserver probably uses log4j because any random Java project probably does, etc.

[owenthejumper]

for LB use cases, HAProxy is doing really well

[GoblinSlayer]

nginx just has logical errors in addition to buffer overflows, e.g. CVE-2026-42946.