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

Original Article ↗ Hacker News Discussion ↗

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.