Nguồn: agwa.name (via Hacker News)
Tóm tắt
Tác giả Andrew Ayer lập luận rằng FastCGI — giao thức ra đời năm 1996 — vẫn là lựa chọn tốt hơn HTTP cho communication giữa reverse proxy và backend. Vấn đề cốt lõi của HTTP/1.1 là không có explicit framing: message tự mô tả điểm kết thúc của nó theo nhiều cách khác nhau với vô số edge cases, dẫn đến HTTP desync attacks (request smuggling). Đây không phải vấn đề có thể vá được — James Kettle liên tục tìm thấy các vulnerability mới, và vào năm 2025 đã tuyên bố “HTTP/1.1 must die”.
FastCGI giải quyết hai vấn đề mà HTTP gặp phải trong reverse proxy context. Thứ nhất, nó có explicit binary framing rõ ràng từ năm 1996, loại bỏ hoàn toàn khả năng desync. HTTP/2 cũng giải quyết được vấn đề này nhưng nginx chỉ hỗ trợ HTTP/2 backends từ cuối 2025, và Apache vẫn đang ở trạng thái “experimental”. Thứ hai, FastCGI có domain separation tường minh giữa headers từ client (prefix với HTTP_) và thông tin trusted từ proxy (như REMOTE_ADDR). Trong HTTP, việc phân biệt X-Real-IP hay True-Client-IP đặt ra minefield bảo mật vì client có thể inject header giả mạo.
Về mặt thực tiễn, các proxy phổ biến (Apache, Caddy, nginx, HAProxy) đều hỗ trợ FastCGI. Trong Go, chỉ cần thay http.Serve bằng fcgi.Serve từ standard library; code handler giữ nguyên. Nhược điểm: không hỗ trợ WebSockets, tooling kém hơn (curl không hỗ trợ FastCGI), và code paths chưa được tối ưu bằng HTTP. Tác giả đã sử dụng FastCGI cho SSLMate trong hơn 10 năm và kết luận rằng với các workload không cần WebSocket, đây là lựa chọn an toàn hơn đáng kể về mặt bảo mật.