Live data from Hacker News

Show HN: I'm rewriting a web server written in Rust for speed and ease of use

ferron.sh

31–40 of 100 posts

Re: Show HN: I'm rewriting a web server written in Rust for speed and ease of use

#32

I know it's not popular to care about these things these days, but please consider a different installation mechanism than curl piped into sudo bash. It's irresponsible and normalizes a practice that never should've happened.

Can we stop with this nonsense already? If you trust them enough to run their server code, why wouldn't you trust them with the installation script?

Re: Show HN: I'm rewriting a web server written in Rust for speed and ease of use

#33
post #28

Looks awesome, but the docs page seems to be returning a 200 yet is completely empty and is showing `x-ferron-cache: HIT` header. Maybe a misconfiguration somewhere?

Works perfectly fine here in Brave/Chromium

Not sure if this will help to debug. Definitely not working for me in Safari. Could be a downstream cache I guess? The browser is using iCloud Private relay. I have "disable cache" checked in the network inspector. The only plugin installed is 1password, but I get the same problem when disabled. Restarted browser with same issue. Seems to work when in private mode, but not without.

Summary

URL: https://ferron.sh/docs

Status: 200

Source: Network

Request

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8

Accept-Encoding: gzip, deflate, br

Accept-Language: en-GB,en;q=0.9

Priority: u=0, i

Sec-Fetch-Dest: document

Sec-Fetch-Mode: navigate

Sec-Fetch-Site: none

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.6 Safari/605.1.15

Response

Accept-Ranges: bytes

Cache-Control: public, max-age=900

Content-Encoding: br

Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline'; object-src 'none'; img-src 'self' data:; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://analytics.ferron.sh; connect-src 'self' https://analytics.ferron.sh

Content-Type: text/html

Date: Tue, 21 Oct 2025 10:07:46 GMT

ETag: W/"ba17d6fadf70c9f0f3b08511cd897f939b6130afbed2906b841119cd7fe17a39-br"

Server: Ferron

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Vary: Accept-Encoding, If-Match, If-None-Match, Range

X-Content-Type-Options: nosniff

x-ferron-cache: HIT

X-Frame-Options: deny

Re: Show HN: I'm rewriting a web server written in Rust for speed and ease of use

#34

I know it's not popular to care about these things these days, but please consider a different installation mechanism than curl piped into sudo bash. It's irresponsible and normalizes a practice that never should've happened.

Can we stop with this nonsense already? If you trust them enough to run their server code, why wouldn't you trust them with the installation script?

I don’t trust them enough to run as root.

Re: Show HN: I'm rewriting a web server written in Rust for speed and ease of use

#35
post #22

Earlier quoted context omitted.

This is kinda funny, but what is a better alternative for new projects on Linux?

it's a rust project which tries to claim the ability to build static binaries, you should be able to just download the server binary.

Yes it seems the binaries are here: https://ferron.sh/download

I will say that though, it's probably not rational to be okay with blindly running some opaque binary from a website, but then flip out when it comes to running an install script from the same people and domain behind the same software. At least from security PoV I don't see how there should be any difference, but it's true that install scripts can be opinionated and litter your system by putting files in unwanted places so nevertheless there are strong arguments outside of security.

Re: Show HN: I'm rewriting a web server written in Rust for speed and ease of use

#36
I wrote my own web server from scratch last year the exact same reasons: starting from scratch with Apache and NGINX is too painful for my needs.

Here are my learnings:

* TLS (HTTPS) can be easily enabled by default, but it requires certificates. This requires a learning curve for the application developer but can be automated away from the user.

* The TLS certs will not be trusted by default until they are added to the OS and browser trust stores. In most cases this can be fully automated. This is most simple in Windows, but Firefox still makes use of its own trust store. Linux requires use of a package to add certs to each browser trust store and sudo to add to the OS. Self signed certs cannot be trusted in OSX with automation and requires the user to manually add the certs to the keychain.

* Everything executes faster when WebSockets are preferred over HTTP. An HTTP server is not required to run a WebSocket server allowing them to run in parallel. If the server is listening for the WebSocket handshake message and determines the connection to instead be HTTP it can allow both WebSocket and HTTP support from the same port.

* Complete user configuration and preferences for an HTTP or WebSocket server can be a tiny JSON object, including proxy and redirection support by a variety of addressable criteria. Traffic redirection should be identical for WebSocks and HTTP both from the users perspective as well as the internal execution.

* The server application can come online in a fraction of a second. New servers coming online will also take just milliseconds if not from certificate creation.

Re: Show HN: I'm rewriting a web server written in Rust for speed and ease of use

#37

> Any feedback is welcome! Read https://www.joelonsoftware.com/2006/12/09/simplicity/ and ask yourself if you are truly solving anyone's problem or if you are just looking for a way to rationalize the amount of time you are spending on a hobby.

Wow, what a harsh comment. You make it sound like we should squeeze any form of efficiency out of people or you're wasting time

Re: Show HN: I'm rewriting a web server written in Rust for speed and ease of use

#40

I know it's not popular to care about these things these days, but please consider a different installation mechanism than curl piped into sudo bash. It's irresponsible and normalizes a practice that never should've happened.

Can we stop with this nonsense already? If you trust them enough to run their server code, why wouldn't you trust them with the installation script?

Because untrustworthy websites can piggyback on the brand name.

"Download ffmpeg here: sudo bash -c ..."

And then the installation script from our malicious site installs ffmpeg just fine, plus some stuff you have no idea about. And you never know that you've just been hacked.

Post reply on HN