3 ms·

> So I'd rather just have my application speak HTTP over a Unix or IP socket that my frontend webserver proxies to. "Each HTTP-serving lib is another liability"

> So I'd rather just have my application speak HTTP over a Unix or IP socket that my frontend webserver proxies to. "Each HTTP-serving lib is another liability" is at least as true for "each FastCGI-serving lib" given that the FastCGI libs will be obscure (less well-tested and maintained) and (due to poorer familiarity/tooling) harder to debug. True-ish, but complicated a bit because (as far as I can tell) the FastCGI spec is tiny compared to HTTP... even just HTTP 1.1, let alone 2 and (yikes) 3.

scottlamb 3y ago
> True-ish, but complicated a bit because (as far as I can tell) the FastCGI spec is tiny compared to HTTP... even just HTTP 1.1, let alone 2 and (yikes) 3. That's true-ish also. For this back leg, it's fine to only support HTTP/1.1; the frontend server can handle translation from HTTP/{2,3} as necessary. And the HTTP/1.1 spec defines a lot of stuff like the syntax/semantics of the headers and semantics of different request methods that the FastCGI spec doesn't address. It's still probably true that the HTTP/1.1 wire format a bit more complex than FastCGI, but it's much closer than it might first appear. On balance I'd still take HTTP any day.