Show HN: Hosting my website using my C web server

Original Article ↗ Hacker News Discussion ↗

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.