Show HN: Hosting my website using my C web server
A hobby project to host a personal website on a hand‑rolled C HTTP/1.1 server sparks broader debate over when it makes sense to build your own infrastructure instead of relying on “battle‑tested” tools like nginx or CDNs. Commenters praise the educational value, simplicity, and small footprint of a custom server, but repeatedly warn about security risks, correctness gaps, and missing features such as chunked encoding and robust TLS handling. The thread also revisits the role of reverse proxies, with some seeing them as essential for security, flexibility, and operations, and others arguing they are often added out of habit rather than clear technical need.
Motivation and Learning Value
- Many commenters like the project as a fun, educational way to understand networking, HTTP, and low-level system APIs.
- Implementing a small HTTP/1.1 server is described as surprisingly tractable and “magical,” especially when it serves real traffic.
- Several people share similar hobby or experimental servers (C, C++, Rust, assembly, LabView), often for blogs or internal tools.
Security and Production Readiness
- Strong warnings that an ad‑hoc C server exposed to the internet is easy to get wrong and could be insecure.
- Others argue that for a personal blog with no sensitive data, the real-world risk and payoff for attackers are low.
- Debate over whether fewer lines of custom code are easier to secure than large, widely used servers; some say community scrutiny of mainstream software outweighs the simplicity advantage of small personal projects.
Static Content, Paths, and Asset Handling
- Discussion of hardcoding file paths or embedding static assets (ROMFS, compiled-in HTML) to avoid filesystem bugs and directory traversal.
- Pushback that this causes recompilation friction and is not worth it for frequent content updates.
- Some use hybrids: baked paths with dynamic file reads, or in-memory caches with reload signals.
HTTP/1.x Scope and Implementation Size
- Consensus that a basic HTTP/1.0 or reduced HTTP/1.1 implementation is small: only GET, Content-Length, minimal headers.
- Features like chunked transfer, range requests, and full spec compliance are optional; the project intentionally rejects client chunked uploads.
- Comparisons to other small HTTP servers show similar code size ranges.
Performance, Scaling, and HN Traffic
- The server reportedly survived the HN front page; commenters note that HN traffic is modest and many simple setups can handle it.
- Some argue a VPS + nginx or lighttpd is more than enough for static sites; CDNs are “boring but optimal” if you truly care about scale.
Reverse Proxies, TLS, and Ops Concerns
- Big subthread on whether reverse proxies (nginx, Caddy, etc.) are necessary.
- Pro-proxy arguments: TLS termination, serving static files efficiently, virtual hosting on one IP, caching, rate-limiting, WAF, blue‑green deployments, shared ops controls, and isolation of a small, hardened edge component.
- Anti/cautious view: for a single simple app that already speaks HTTPS, a proxy can be needless complexity and adds latency; many uses are labeled habitual or “cargo cult,” though others contest that label as unfair.
Language Choices and C’s Role
- Debate over C’s modern relevance: some see it as dangerous and archaic, others as simple, powerful, and foundational.
- Memory‑safe languages (Rust, higher-level stacks) are cited as safer and faster to develop in, but several insist that understanding C and pointers is still important for serious systems work.