The article argues that HTTP is fundamentally flawed for reverse proxy-to-backend communication due to desync/request smuggling vulnerabilities and untrusted header issues. FastCGI, a 30-year-old wire protocol, solves these problems cleanly.

Why HTTP Sucks for Reverse Proxies

Desync Attacks / Request Smuggling: HTTP/1.1 lacks explicit message framing — the message itself describes where it ends, with multiple ambiguous ways to do so. Different parsers (proxy vs backend) can disagree on message boundaries, enabling attacks. James Kettle, after finding another batch last year, declared “HTTP/1.1 must die”. HTTP/2 fixes this when used consistently, but adoption has been slow: nginx only got HTTP/2 backend support in late 2025, and Apache's support is still “experimental”.

Untrusted Headers: There's no robust way for a proxy to pass trusted info (client IP, auth details, mTLS certs) to the backend without mixing with attacker-controlled client headers. Proxies must carefully delete all instances of headers like X-Real-IP before adding their own — easy to get wrong. FastCGI has separate parameter channels (e.g., REMOTE_ADDR, AUTH_TYPE) that are structurally distinct from request data.

FastCGI: A Wire Protocol, Not a Process Model

FastCGI can be used like HTTP — send requests over TCP/UNIX sockets to a long-running daemon. In Go, switching is trivial:
import "net/http/fcgi"
Replace http.Serve(l, handler) with fcgi.Serve(l, handler). Your handler still uses standard http.ResponseWriter and http.Request.

Proxy Configuration Examples

nginx:

# HTTP
proxy_pass http://localhost:8080;

FastCGI
fastcgi_pass localhost:8080;
include fastcgi_params;

Apache:

# HTTP
ProxyPass / http://localhost:8080/

FastCGI
ProxyPass / fcgi://localhost:8080/

Caddy:

# HTTP
reverse_proxy localhost:8080 {
    transport http { }
}

FastCGI
reverse_proxy localhost:8080 {
    transport fastcgi { }
}

HAProxy:

# HTTP
backend app_backend
    server s1 localhost:8080

FastCGI
fcgi-app fcgi_app
    docroot /
backend app_backend
    use-fcgi-app fcgi_app
    server s1 localhost:8080 proto fcgi

Popular proxies like Apache, Caddy, nginx, and HAProxy all support FastCGI backends with simple config changes.

Key Takeaway

FastCGI has had explicit message framing since 1996 (simple header with content length, no ambiguity) and separate trusted parameter channels. Switching from HTTP to FastCGI between proxy and backend eliminates an entire class of vulnerabilities without sacrificing functionality.