What's your choice for an internet-facing web server, in 2024? Security over performance, ease (or lack) of configuration is a bonus; presence in Debian or Ubuntu preferred but anything I can build from source (so, probably not written in go) and has a good CVE story is of interest.
- Apache (19%, 94 votes)
- nginx (53%, 261 votes)
- lighttpd (2%, 12 votes)
- caddy (21%, 104 votes)
- webfs (0%, 0 votes)
- Anything else (explain (or name) in thread) (4%, 20 votes)
Chris Siebenmann
in reply to Mark Eichin • • •I voted Apache because it's what we use at work (a university department) and it's very flexible; we can do pretty much anything we need to with it (and we know how to). For straightforward or lightweight stuff my impression is that nginx may be cleaner.
I used to really like lighttpd's core pitch and ran it some places, but my sad impression is that it's stagnated, especially in support for the latest TLS things, HTTP/2+, etc. At this point I wouldn't use it for new deployments.
silverwizard
in reply to Mark Eichin • •Mark Eichin
in reply to silverwizard • • •Basic Webserver (httpd)
www.openbsdhandbook.comsilverwizard likes this.
silverwizard
in reply to Mark Eichin • •Mark Eichin
Unknown parent • • •Mark Eichin
Unknown parent • • •@raggi yeah, npm and python have related issues; rust "plays nicely" with C in ways that probably reduce friction there but I haven't yet run into a reason to dig in enough to see if that's true.
There is a newish "gophian" go→deb auto-packager (like dh-make-golang but from a different angle) but it isn't quite automatic enough for this (I owe someone some bug reports on that of course)
Dan Jones
in reply to Mark Eichin • • •I recently switched from nginx to caddy, and I couldn't be happier, and have no idea why I took so long. It's easier to configure for all common use cases, and automatic LetsEncrypt integration is killer.
@eichin@mastodon.mit.edu
Captain Steph
in reply to Mark Eichin • • •Mark Eichin
in reply to Captain Steph • • •Thanks. (From my perspective, that counts as caddy...)
Captain Steph
in reply to Mark Eichin • • •Glyph
in reply to Mark Eichin • • •twisted, obvi
caddy would probably be my second choice, if I had to stick to this list; I don't love the fact that twisted's TLS support is in C, but why would I put a whole-ass C _HTTP_ parser on the internet in 2024?
Mark Eichin
in reply to Glyph • • •Glyph
in reply to Mark Eichin • • •Mark Eichin
in reply to Glyph • • •@glyph a little after-dinner poking didn't turn up anything in the package changelog - I did find twisted.org/documents/9.0.0/hi… and `tap2deb` rang some vague bells from a *long* time ago. (Surprisingly I didn't find any more of a virtual-package-name policy than references to virtual-package-names-list.yaml which has nothing more than
- name: httpd
description: a HTTP server
Twisted and Debian
twisted.orgMark Eichin
in reply to Glyph • • •mathew
in reply to Mark Eichin • • •@glyph So the problem isn't that you can't build it from source, it's that you can't build Debian source packages from the source and then use Debian tools to build those into a binary?
I've built Caddy from source many times, it's really easy. I run a custom build of it on Debian to host my web site and act as a WebDAV server.
Mark Eichin
in reply to mathew • • •Glyph
in reply to Mark Eichin • • •Alex
in reply to Mark Eichin • • •mathew
in reply to Mark Eichin • • •@glyph Ah, I just cross-compile on a system with a network connection, then rsync the binary since Go binaries are statically linked.
Not sure why Hugo would need protobuf in the first place. I'm guessing it's being dragged in by some other dependency.
Mark Eichin
in reply to mathew • • •@mathew
It's not about "building somewhere else with a network connection" (it's a web server, clearly where I'm running it has net It's about doing "hermetic" builds, where everything is already present (and recorded/traceable/reviewable) at build time, where it doesn't *need* net at all.
There's a lot of not knowing what deps a go project has - and ending up with hundreds of them. "Yay abstraction", but I'm in the "paranoia is a healthy part of this releng breakfast" camp instead.
@glyph
Glyph
in reply to Mark Eichin • • •Mark Eichin
in reply to Glyph • • •I don't actually know (the compiler errors only had paths, not versions, and I ran out of time figuring out why just deleting the vendored copy wasn't working [*that* was probably non-go-specific debian Quilt flailing though.])
@mathew
Ukiah Danger Smith
in reply to Mark Eichin • • •@mathew @glyph
For you, what is the "not knowing" part of Go app dependencies?
Is go.mod go.sum not enough to know the full list? Or do you mean more of what's in the dependency itself?
Marko Karppinen
in reply to Mark Eichin • • •Mark Eichin
in reply to Marko Karppinen • • •HAProxy SSL Termination (Offloading) Everything to Know
Nick Ramirez (HAProxy Technologies)gigantos
in reply to Mark Eichin • • •Mark Eichin
in reply to gigantos • • •Traefik Configuration Discovery Overview - Traefik
doc.traefik.ioandrethemac
in reply to Mark Eichin • • •Mark Eichin
in reply to andrethemac • • •PointlessOne
in reply to Mark Eichin • • •My default is nginx. It's robust, it's everywhere, it's well maintained, and I know it.
But depending on what you're trying to achieve other options might be better. Cadddy seems simpler if you need HTTPS with Let’s Encrypt and just reverse proxy, or static files served.
If you're something dynamic (e.g. Python/Ruby/PHP app) check out nginx unit.
Mark Eichin
in reply to PointlessOne • • •NGINX Unit: Key features
unit.nginx.orgMarcus Bointon
in reply to Mark Eichin • • •Mark Eichin
in reply to Marcus Bointon • • •@Synchro ooh, I'd missed mod_md (or perhaps I saw it and assumed it was something silly with markdown handling
Do you find you actually need HTTP/3 for anything? At first glance, it looks like it only has performance benefits in some extreme cases...
Marcus Bointon
in reply to Mark Eichin • • •Alda Vigdís 🇵🇸 🇱🇧
in reply to Mark Eichin • • •HeadPlug
in reply to Mark Eichin • • •Funky Bob
in reply to Mark Eichin • • •Mark Eichin
in reply to Funky Bob • • •GitHub - h2o/h2o: H2O - the optimized HTTP/1, HTTP/2, HTTP/3 server
GitHub