I suspect that people don't like changing web servers, and perhaps that's why it took the industry so long to move away from Apache. Ferron actually looks great — great performance, automatic TLS, easy reverse proxy configuration and more. Congrats on shipping this!
Please consider out-of-the-box way to analyze slow queries, analysis by endpoints (ideally with some patterns to group by), ideally to not generate gigabytes of access logs but rather give some already-aggregated in-memory stats.
Maybe batteries included would be great (web UI similar to HAProxy but way-way better).
I am a FOSS developer myself for many years, and this is exactly kind of stuff I'd love to hear. So no, it is totally OK to give your ideas to the developer in this form.
I wouldn't. Blazing fast, fearless concurrency, etc. are all super cringe at this point. Just say it's fast, secure and reliable or something like that.
Thank you for the feedback! I think this is an advantage of Rust that prevents common pitfalls related to concurrent programming, making web servers written in Rust safer.
Yes, I know that both Axum and Actix Web exist. However, these are web application frameworks designed for building web applications in Rust. On the other hand, my project is a standalone web server, similar to Apache httpd, NGINX, or Caddy.
While there are standalone web servers in Rust, such as Static Web Server and binserve, they primarily focus on serving static files rather than providing general-purpose web hosting capabilities. My goal is to create a more versatile web server that can handle a wider range of web hosting applications.
Pingora is not a standalone web server (like NGINX or Apache httpd), it's a Rust-based framework developed by Cloudflare for building network services, particularly HTTP proxies.
River (built on Pingora) is designed to be a reverse proxy. My web server on the other hand is designed to be a general-purpose web server (it also supports reverse proxying).
It sounds like this is a general purpose web server rather than a web framework like axum and actix-web. It's in the category of nginx, apache or caddy.
This web server is probably awesome. However "memory-safe" isn't distinguishing within the Rust ecosystem. There's... a lot... of Rust web servers out there, all of which are presumably memory-safe, because Rust:
I was looking for a web server, not a web framework. A replacement for nginx and caddy, not something to build applications on thus I never would have thought about clicking on a link talking about web frameworks.
Anybody have any suggestions beyond the one under discussion?
Thank you! Many other web server written in Rust are memory-safe as well, because of Rust's borrow checker.
I designed Ferron to be a general-purpose, standalone web server, just like NGINX or Caddy. It can even run PHP web applications (through FastCGI).
You’re right, but the state of play is even better than you suggest because there’s a lot of memory safe web servers outside of Rust too. Eg Go.
And that’s not even counting all the webservers included as part of their backend frameworks in Python, node.js, Java, etc.
web servers written in unsafe languages are really the minority but those that do exist are largely so heavily battle tested that a rewrite would likely introduce new sources of bugs (eg Apache and nginx).
If there’s one domain that’s seen a lot of competition for security, it’s been web servers.
I use caddy and I'm quite happy with it over apache and nginx, but I'd happily give my opinion if this helps OP to make this something different and hopefully even better than caddy.
I love auto TLS and caddyfiles are easy to understand. Modularity is important and templates can be very useful. Serving files and using caddy as reverse proxy are the most common uses I make of it in production, but I also use caddy in dev and it's a boon. Ease of config means my team can easily pick up my work and continue from there, even if they are not as proficient with the tool.
I don't love caddyfile directive ordering: sometimes my colleagues are confused because directives have an implicit order that is not obvious: instead of reordering directives, I'd rather have a warning/error message saying "this config doesn't make sense because you cannot do this and that", or just follow the order used in the config file + warnings.
I use it a lot to prototype and mock APIs during development, e.g. to have endpoints returning html pages or json documents: static files and templates are useful for this and I wouldn't consider something without this feature, though go templates aren't that great and/or caddy docs are a bit lacking (e.g. a simple loop over 0,1,2,3... Is not obvious!)
I don't find caddy great (or I don't know how to use it) to debug things when they are not working as expected. I often find myself replacing parts of the infra with netcat so that I can inspect what is going on. It would be great to have a "debug endpoint", like a webpage I could connect to and inspect all the traffic like MITM proxy, it would be awesome. Being able to inject myself in a route and manually change headers, responses, requests etc, it would be fantastic and a great help in debugging issues. Also, being able to start this "inspection mode" while in production would be nice, without having to restart the server (something is off -> I ssh-port-forward to the server host -> connect my browser to the server and inspect the errors -> find the issue and fix the config).
Management of certs could be improved in some edge cases. For example, I'd be happy if it was easier to manage certs in a private subnet. For example, say host A could acquire certs for my domain example.com with DNS challenge, then a host B, not public facing but in a subnet with A, could ask A to manage its certificates and still have valid https (letsencrypt provided certs) inside the network.
One thing I also don’t like in caddy is the lack of caching configuration available without using a partially implemented extension. I find it quite important as a reverse proxy with nginx.
I agree with the implicit ordering of marchers in caddy.
Also, while I love Rust and I'm a big fan of the language, please stop saying "it's made with Rust!". Really, it's only annoying and irrelevant to the quality of a project and it might even be counterproductive. Who cares what language is used for a software as long as it works great ;)
This holds in general, not only for this project in particular.
I see that it's written in Rust, besides that, what's your ambition for why an end user would choose this project over one of the established players like Caddy/Traefik/nginx?
I think for this web server to compete with caddy/nginx (if the goal is getting other people to use it, if built for fun, please ignore) this needs a good reason to exist.
Memory-safe is nice compared to Nginx, but pretty moot when comparing to Caddy. OTOH, perhaps this could aim for better/comparable performance to Nginx (and better than Caddy) whilst being memory safe? It’s still quite a niche use case though.
As welcome as the efficiency and performance features are, the convenience of lets encrypt integration in Caddy wins the decision almost all the time. No more certbot cron jobs or worries about having the certs in the right place or permissions etc.
for this to be equivalent to Caddy, that is the most important convenience feature.
I apologise for my low quality comment. I only read the website and did not actually try the web server. It wasn’t highlighted on the homepage(like Caddy does) and I made a tardy assumption.
- Since this is Hacker News, it's likely meant to showcase it to other Rust engineers, or attract contributors
- It signals that it is close to C/C++ speeds, but is more memory-safe than C/C++ servers
- It shows pride in being able to overcome the borrow checker, which can sometimes be difficult (Rust is more of a language + small formal proof of memory safety, than just a language)
I don't mind it, since I like the language, and I'll try to use apps written in Rust when possible. If I see Rust, I know what to expect wrt. resource usage and performance, contributor experience and so on. I'm also willing to test them to "dog-food" the ecosystem.
By default, I expect that the performance, memory usage and start-up time of a Rust app to be comparable to an equivalent one written in C or C++. That's still a range of one or two orders of magnitude, but it's still good enough to have an initial idea.
For example, there's a popular Python app that used to take 1-2 seconds just to display the help message. It's a little better these days, and I'd use it anyway there's no alternative, but there's no way a Rust version of it would be that slow to start.
I suspect that people don't like changing web servers, and perhaps that's why it took the industry so long to move away from Apache. Ferron actually looks great — great performance, automatic TLS, easy reverse proxy configuration and more. Congrats on shipping this!
Yeah it surprised me when Caddy [1] started gaining traction for that reason.
It's much better than the old competition in many ways, so there's that.
https://caddyserver.com
What's wrong with Apache?
It is often slower, harder to configure, and has fewer features than Nginx, Caddy, etc.
Slower? Yes. But my impression was always that it had more features than nginx. Unless you compare it with the enterprise offering?
Thank you for the feedback!
Please consider out-of-the-box way to analyze slow queries, analysis by endpoints (ideally with some patterns to group by), ideally to not generate gigabytes of access logs but rather give some already-aggregated in-memory stats.
Maybe batteries included would be great (web UI similar to HAProxy but way-way better).
This seems to be a bonafide FOSS project, the correct way to ask for features is either to provide patch or money not this..
I am a FOSS developer myself for many years, and this is exactly kind of stuff I'd love to hear. So no, it is totally OK to give your ideas to the developer in this form.
Suggesting features is always good
Is it susceptible to slow loris?
Hyper, the http library, did not handle it well.
I haven't tested it for Slowloris yet.
Awesome :) Best of luck with the project!
Thank you!
I'd mention fearless concurrency on the website/blog post, as that distinguishes your webserver from, say, caddy.
I wouldn't. Blazing fast, fearless concurrency, etc. are all super cringe at this point. Just say it's fast, secure and reliable or something like that.
No it's not.
Thank you for the feedback! I think this is an advantage of Rust that prevents common pitfalls related to concurrent programming, making web servers written in Rust safer.
So deadlock free, or don't you just fear deadlocks, rather ignore the possibility?
thanks for sharing. what's the commercial plans?
i will add to the pile of cgi hosts in our CI for weird and borderline hostile php projects and report back.
Thank you! Right now, I don't have any commercial plans for my web server. My web server is free to use for everyone, and it's open source.
Have you heard of axum[1] or actix-web[2]? What does this do that existing Rust web servers don't?
I think the "web server" ecosystem in Rust is pretty mature by now, so you should probably state in what way your project is novel on the website.
Edit: OK, I realized that this is supposed to be an nginx/caddy replacement, so a complete, configurable web server/proxy. Maybe check out https://github.com/memorysafety/river or https://github.com/sozu-proxy/sozu
[1] https://docs.rs/axum
[2] https://docs.rs/actix-web
Yes, I know that both Axum and Actix Web exist. However, these are web application frameworks designed for building web applications in Rust. On the other hand, my project is a standalone web server, similar to Apache httpd, NGINX, or Caddy.
While there are standalone web servers in Rust, such as Static Web Server and binserve, they primarily focus on serving static files rather than providing general-purpose web hosting capabilities. My goal is to create a more versatile web server that can handle a wider range of web hosting applications.
What about Cloudflare's pengora?
Edit: or https://github.com/memorysafety/river
Edit 2: or https://github.com/sozu-proxy/sozu
Pingora is not a standalone web server (like NGINX or Apache httpd), it's a Rust-based framework developed by Cloudflare for building network services, particularly HTTP proxies. River (built on Pingora) is designed to be a reverse proxy. My web server on the other hand is designed to be a general-purpose web server (it also supports reverse proxying).
https://github.com/cloudflare/pingora seems to be focused on providing a library/framework
It sounds like this is a general purpose web server rather than a web framework like axum and actix-web. It's in the category of nginx, apache or caddy.
I agree with you.
This was my question too so I think it's worth clarifying that on the home page.
I have just added a "What are the differences between Ferron and other web servers written in Rust?" question to Frequently Asked Questions.
You should also add more context on how it's different from Nginx and Caddy as well to that answer, your one above works well [0].
[0] https://news.ycombinator.com/item?id=43228231#43228376
Apparently you need to add "what is a webserver" for these new guys.
It's already in the FAQ section.
This web server is probably awesome. However "memory-safe" isn't distinguishing within the Rust ecosystem. There's... a lot... of Rust web servers out there, all of which are presumably memory-safe, because Rust:
https://github.com/flosse/rust-web-framework-comparison
How does Ferron distinguish itself from these? I didn't get that from skimming the landing page.
I was looking for a web server, not a web framework. A replacement for nginx and caddy, not something to build applications on thus I never would have thought about clicking on a link talking about web frameworks.
Anybody have any suggestions beyond the one under discussion?
Did you click the link? Scroll down to “Server frameworks.”
I don't want a "server framework" I want a server. OP actually built a server.
I clicked through the first few and they talk about building applications with them. That is explicitly what I excluded.
In many cases the difference is whether you write your configuration in a file with a '.yml' extension or a '.rs' extension.
It does mean that you end up with per-app binaries, which is either a pro or a con depending on the use case.
Can they do what caddy does or not without a turing complete language ? That is the question.
Thank you! Many other web server written in Rust are memory-safe as well, because of Rust's borrow checker. I designed Ferron to be a general-purpose, standalone web server, just like NGINX or Caddy. It can even run PHP web applications (through FastCGI).
You’re right, but the state of play is even better than you suggest because there’s a lot of memory safe web servers outside of Rust too. Eg Go.
And that’s not even counting all the webservers included as part of their backend frameworks in Python, node.js, Java, etc.
web servers written in unsafe languages are really the minority but those that do exist are largely so heavily battle tested that a rewrite would likely introduce new sources of bugs (eg Apache and nginx).
If there’s one domain that’s seen a lot of competition for security, it’s been web servers.
I use caddy and I'm quite happy with it over apache and nginx, but I'd happily give my opinion if this helps OP to make this something different and hopefully even better than caddy.
I love auto TLS and caddyfiles are easy to understand. Modularity is important and templates can be very useful. Serving files and using caddy as reverse proxy are the most common uses I make of it in production, but I also use caddy in dev and it's a boon. Ease of config means my team can easily pick up my work and continue from there, even if they are not as proficient with the tool.
I don't love caddyfile directive ordering: sometimes my colleagues are confused because directives have an implicit order that is not obvious: instead of reordering directives, I'd rather have a warning/error message saying "this config doesn't make sense because you cannot do this and that", or just follow the order used in the config file + warnings.
I use it a lot to prototype and mock APIs during development, e.g. to have endpoints returning html pages or json documents: static files and templates are useful for this and I wouldn't consider something without this feature, though go templates aren't that great and/or caddy docs are a bit lacking (e.g. a simple loop over 0,1,2,3... Is not obvious!)
I don't find caddy great (or I don't know how to use it) to debug things when they are not working as expected. I often find myself replacing parts of the infra with netcat so that I can inspect what is going on. It would be great to have a "debug endpoint", like a webpage I could connect to and inspect all the traffic like MITM proxy, it would be awesome. Being able to inject myself in a route and manually change headers, responses, requests etc, it would be fantastic and a great help in debugging issues. Also, being able to start this "inspection mode" while in production would be nice, without having to restart the server (something is off -> I ssh-port-forward to the server host -> connect my browser to the server and inspect the errors -> find the issue and fix the config).
Management of certs could be improved in some edge cases. For example, I'd be happy if it was easier to manage certs in a private subnet. For example, say host A could acquire certs for my domain example.com with DNS challenge, then a host B, not public facing but in a subnet with A, could ask A to manage its certificates and still have valid https (letsencrypt provided certs) inside the network.
One thing I also don’t like in caddy is the lack of caching configuration available without using a partially implemented extension. I find it quite important as a reverse proxy with nginx.
I agree with the implicit ordering of marchers in caddy.
Also, while I love Rust and I'm a big fan of the language, please stop saying "it's made with Rust!". Really, it's only annoying and irrelevant to the quality of a project and it might even be counterproductive. Who cares what language is used for a software as long as it works great ;)
This holds in general, not only for this project in particular.
I don't find it annoying and it's not totally irrelevant to the quality of the project.
I'd MUCH rather a hobby web server be written in rust than C++ or C. I'm not touching the latter with a ten foot pole.
I see that it's written in Rust, besides that, what's your ambition for why an end user would choose this project over one of the established players like Caddy/Traefik/nginx?
I think for this web server to compete with caddy/nginx (if the goal is getting other people to use it, if built for fun, please ignore) this needs a good reason to exist.
Memory-safe is nice compared to Nginx, but pretty moot when comparing to Caddy. OTOH, perhaps this could aim for better/comparable performance to Nginx (and better than Caddy) whilst being memory safe? It’s still quite a niche use case though.
According to the landing page, it already outperforms Caddy.
So does nginx. Still Caddy keeps eating a slice of nginx pie.
> performs similarly to a popular Caddy web server
From the main landing page. Possibly the benchmarks are slightly better, but until Nginx is added it’s hard to say how significant that bump is.
I will later update the performance benchmark chart, since the current one features an earlier alpha version of my web server (Project Karpacz 0.3.0).
How many memory safety issues are found per year in the established servers (Apache and nginx)?
Why does the front page benchmark not include nginx?
Why doesn’t benchmark include Ferron itself?
It includes an older, alpha version of my web server (Project Karpacz 0.3.0). I will update the benchmark later.
1) The graph still shows karpacz, which is super confusing.
2) Where's nginx in this graph? It feels very disingenuous. Esp when serving a default nginx page
[flagged]
As welcome as the efficiency and performance features are, the convenience of lets encrypt integration in Caddy wins the decision almost all the time. No more certbot cron jobs or worries about having the certs in the right place or permissions etc. for this to be equivalent to Caddy, that is the most important convenience feature.
Of course, my web server supports automatic TLS (through TLS-ALPN-01 challenge), just like Caddy.
I apologise for my low quality comment. I only read the website and did not actually try the web server. It wasn’t highlighted on the homepage(like Caddy does) and I made a tardy assumption.
[flagged]
I can think of at least a few things:
- Since this is Hacker News, it's likely meant to showcase it to other Rust engineers, or attract contributors
- It signals that it is close to C/C++ speeds, but is more memory-safe than C/C++ servers
- It shows pride in being able to overcome the borrow checker, which can sometimes be difficult (Rust is more of a language + small formal proof of memory safety, than just a language)
Actually, I spent some time "fighting the borrow checker" when I developed my web server.
I don't mind it, since I like the language, and I'll try to use apps written in Rust when possible. If I see Rust, I know what to expect wrt. resource usage and performance, contributor experience and so on. I'm also willing to test them to "dog-food" the ecosystem.
What are your performance expectations?
By default, I expect that the performance, memory usage and start-up time of a Rust app to be comparable to an equivalent one written in C or C++. That's still a range of one or two orders of magnitude, but it's still good enough to have an initial idea.
For example, there's a popular Python app that used to take 1-2 seconds just to display the help message. It's a little better these days, and I'd use it anyway there's no alternative, but there's no way a Rust version of it would be that slow to start.
[flagged]
What does this comment practically add to the discourse of curiosity?