3 ms·
My reply would be pretty much what scottlamb said already. Of course HTTP daemons are nice, but these days they can just reverse proxy an actual HTTP service on
by debugnik 3y ago
My reply would be pretty much what scottlamb said already. Of course HTTP daemons are nice, but these days they can just reverse proxy an actual HTTP service on a given route instead of using some knock-off protocol like FastCGI; you need a protocol and library either way, so FastCGI isn't an advantage there.
- wharvle 3y agoMy experience is that they almost always end up being "just" a dumb pipe, then. Routing (beyond proxying requests to backend servers), request logging, bi-directional interaction with the backend code that can enable cool stuff like conditional direct-serving of files, error handling, all kinds of great stuff available with server modules—that all ends up unused, because the HTTP daemon and the "application" end up different places, and making them work tightly together to let each do what it's best at becomes impractical. [EDIT] And, as noted in my response to the other reply here, the size of the FastCGI spec, and the size of implementations, are far smaller than HTTP, which is nice.