5 ms·

It's written in C, which is part of the problem. I'd be very interested in a similarly-featured webserver (reverse proxy, mostly) which is written in a memory-s

It's written in C, which is part of the problem. I'd be very interested in a similarly-featured webserver (reverse proxy, mostly) which is written in a memory-safe language.

atmosx 10y ago
Caddy[1] is written in Go and has a nicer, simpler syntax. I'm sure NGINX has many more features though. [1] https://github.com/mholt/caddy https://github.com/mholt/caddy
- fortytw2 10y ago
  Caddy has less than half the performance of Nginx - not really a viable replacement at any sort of scale. https://hackernoon.com/caddy-a-modern-web-server-vs-nginx-e9e4abc443e#.wps7udz6x https://hackernoon.com/caddy-a-modern-web-server-vs-nginx-e9...
  - Filligree 10y ago
    Depends on what you're doing. If it's fronting an expensive web-app, then the couple hundred CPU-microseconds needed to proxy a request isn't going to be noticeable... Caddy can serve 5,000 requests per second per core. I would flip your statement on its head, and say that a minority of people need anything close to that. The few companies that do, can probably afford to keep on top of CVEs for their frontends as well.
  - shawabawa3 10y ago
    That's misleading at best. Empty request benchmarks are indicative of nothing in the real world. For any reasonable workload, even serving static sites of a few kilobytes they will be effectively the same. Caddy's sane default settings (enforcing SSL, and with correct settings to get an A+ on SSL labs) make it the right choice for a lot of deployments
- rnhmjoj 10y ago
  Ironically as I was considering Caddy as an NGINX alternative I found about a security issue that is very reminiscent of what happened at cloudflare: https://github.com/mholt/caddy/issues/1204#issuecomment-278193792 https://github.com/mholt/caddy/issues/1204#issuecomment-2781...
Klathmon 10y ago
Well, as nice as that sounds on paper, there's a reason we use reverse-proxies in the first place. It's because it turns out that opening anything up to the web is a whole can of worms of exploits, malformed requests, differently complying useragents, tons of standard, nonstandard, and "crazy off the wall bullshit" headers, and a LOT more. Greenfield writing a new safe reverse proxy that works within a magnitude of performance of something like nginx is a monumental effort. Not to mention the chicken-and-egg problem of how nobody will trust it until it has significant usage which it won't get until some people trust it.

It's written in C, which is part of the problem. I'd be very interested in a similarly-featured webserver (reverse proxy, mostly) which is written in a memory-safe language.

atmosx 10y ago

Caddy[1] is written in Go and has a nicer, simpler syntax. I'm sure NGINX has many more features though. [1] https://github.com/mholt/caddy https://github.com/mholt/caddy

fortytw2 10y ago
Caddy has less than half the performance of Nginx - not really a viable replacement at any sort of scale. https://hackernoon.com/caddy-a-modern-web-server-vs-nginx-e9e4abc443e#.wps7udz6x https://hackernoon.com/caddy-a-modern-web-server-vs-nginx-e9...
- Filligree 10y ago
  Depends on what you're doing. If it's fronting an expensive web-app, then the couple hundred CPU-microseconds needed to proxy a request isn't going to be noticeable... Caddy can serve 5,000 requests per second per core. I would flip your statement on its head, and say that a minority of people need anything close to that. The few companies that do, can probably afford to keep on top of CVEs for their frontends as well.
- shawabawa3 10y ago
  That's misleading at best. Empty request benchmarks are indicative of nothing in the real world. For any reasonable workload, even serving static sites of a few kilobytes they will be effectively the same. Caddy's sane default settings (enforcing SSL, and with correct settings to get an A+ on SSL labs) make it the right choice for a lot of deployments
rnhmjoj 10y ago
Ironically as I was considering Caddy as an NGINX alternative I found about a security issue that is very reminiscent of what happened at cloudflare: https://github.com/mholt/caddy/issues/1204#issuecomment-278193792 https://github.com/mholt/caddy/issues/1204#issuecomment-2781...

Klathmon 10y ago

Well, as nice as that sounds on paper, there's a reason we use reverse-proxies in the first place. It's because it turns out that opening anything up to the web is a whole can of worms of exploits, malformed requests, differently complying useragents, tons of standard, nonstandard, and "crazy off the wall bullshit" headers, and a LOT more. Greenfield writing a new safe reverse proxy that works within a magnitude of performance of something like nginx is a monumental effort. Not to mention the chicken-and-egg problem of how nobody will trust it until it has significant usage which it won't get until some people trust it.