FastCGI: 30 years old and still the better protocol for reverse proxies

Original Article ↗ Hacker News Discussion ↗

FastCGI is being re-evaluated as a safer, more robust protocol than HTTP for communication between reverse proxies and backend applications, largely because it cleanly separates trusted metadata from untrusted client headers and avoids many HTTP parsing pitfalls. Commenters weigh this security and performance benefit against the ubiquity and simplicity of using HTTP end‑to‑end, noting that modern stacks, cloud tooling, and developer workflows overwhelmingly assume HTTP even if it is “worse is better.” Alternatives like uWSGI, custom protocols, and embedded HTTP servers are mentioned, but most agree that careful header allowlisting or dedicated front-end firewalls are essential when HTTP is used between internal services.

FastCGI vs HTTP for Reverse Proxying

  • Many agree FastCGI is technically safer and simpler than HTTP as a backend protocol: clearer framing, separation between client headers and server-set parameters, and fewer parsing footguns.
  • HTTP “won” historically due to ubiquity and simplicity: one protocol everywhere, easier multi-layer proxy topologies, same app server for dev and prod, and strong nginx support.
  • Using HTTP between reverse proxies and backends is seen by some as a “worse is better” story: not ideal technically, but good enough and broadly supported.

Security, Headers, and Design Principles

  • FastCGI lets the web server control which parameters are trusted; headers from the client are clearly separated (e.g., via HTTP_-prefixed vars).
  • HTTP backends are vulnerable to untrusted or conflicting headers (X-Forwarded-For, X-Real-IP, CDN-specific headers, etc.), and cross-proxy parsing/desync problems.
  • One camp favors end-to-end HTTP for flexibility; another argues for least-privilege and strict allowlisting at the proxy, even if that’s operationally less convenient.
  • Suggestions include stripping all unknown headers at the proxy or using standardized headers like Forwarded, though adoption is uneven.

Developer Experience and Deployment Patterns

  • Embedded HTTP servers in apps are popular for simplicity, but many libraries explicitly warn they’re not production-safe; this pushes people back to reverse proxies.
  • Some dislike having separate modes (HTTP for dev, FastCGI for prod) due to divergence between environments.
  • Others argue that if production uses a proxy, dev should too, to stay realistic.

Alternatives and Variants

  • uWSGI is praised as a compact, feature-rich binary protocol (autoscaling, websockets, chrooting), but seen as underused and somewhat in decline.
  • Custom protocols like Web Application Socket (WAS) are presented as FastCGI-like but more efficient (control socket + pipes, cancellable requests).
  • CGI is revisited as “good enough” for small, “person-scale” workloads, though its env-var header model has known security issues (e.g., httpoxy).

Limitations & Practical Concerns

  • FastCGI lacks native WebSocket support; SSE and streaming HTTP can cover some use cases.
  • Some note FastCGI’s CGI heritage introduces quirks (e.g., lossy handling of certain URL/path encodings).
  • Operationally, autoscaling FastCGI workers can cause memory surprises; fixed worker counts are preferred by some.