Show HN: I built a web framework in C

Original Article ↗ Hacker News Discussion ↗

Motivation and Intended Use

  • Author states it’s mainly “for fun” and to make C feel like a higher‑level language.
  • Several commenters see it as well-suited for embedded/IoT devices or C daemons that need a small web UI, not public-internet production servers.
  • Even supportive commenters note that existing frameworks (Django, Rails, Express, Go, etc.) are usually more practical for typical web apps.

C vs. Memory-Safe Languages for Web Servers

  • One camp argues that memory-safe languages eliminate entire classes of vulnerabilities (buffer overflows, UAF, etc.), which is especially important for web servers.
  • Others respond that C can be used safely with standards (SEI/MISRA), static analysis, sanitizers, and review; the key is engineering discipline, not the language alone.
  • A subthread debates whether it’s fair to dismiss a C framework as “a terrible idea” without reviewing its actual code, vs. warning juniors that C is usually the wrong choice for web apps.

Code Quality, Style, and Specific Criticisms

  • Many praise the code as unusually clean, modern, minimal-dependency C and a good learning reference.
  • Others strongly disagree, calling it a poor example of production-grade C:
    • scarce error checking (malloc/snprintf),
    • unsafe realloc usage (potential leaks and missing NULL checks),
    • over-engineered .env parser that makes bugs harder to spot.
  • appRoute macro for route handlers is seen by some as neat and by others as unnecessary obfuscation.

Security and HTTP Parsing Risks

  • Multiple comments warn that rolling an HTTP parser in C is “very dangerous” without extensive fuzzing and tests; better to build on battle-tested libs (libmicrohttpd, libevent_http, FastCGI).
  • At least one heap overflow in the HTTP parser is reported, with an exploit demo likened to Heartbleed.
  • Several advise treating this as a learning project, not a production web server.

Architecture, Features, and Future Work

  • Suggestions include: non-blocking I/O and event loop, support for partial reads/writes, per-request arenas, threading or libuv, IPv6 sockets, HTTPS/TLS, better auth semantics, and HTML templating.
  • Some recommend safer naming to avoid global symbol collisions and using CodeQL/static analysis.

Learning, AI, and Meta Discussion

  • Many applaud it as an educational project and example of “how to write C in 2025,” and ask about the author’s learning path.
  • There’s concern about AI-written sections (e.g., JSON) in a network-facing C project.
  • A moderator highlights HN’s “contrarian dynamic”: early shallow negativity followed by later, more upvoted defenses, urging more reflective, substantive criticism.