3 ms·

> In fcgi mode it runs as a service listening to a socket and reads and sends response over it while never terminating. What's the point of using this over ser

> In fcgi mode it runs as a service listening to a socket and reads and sends response over it while never terminating. What's the point of using this over serving HTTP directly? The whole point of CGI was providing an easy to implement interface to proper HTTP servers, but FastCGI is such as step up in complexity compared to CGI that you're going to need a library anyway. Maybe FastCGI made sense back when companies tried to convince us we needed their heavy-duty software to handle any HTTP traffic at all, but now HTTP libraries and reverse proxies are dime a dozen.

wharvle 3y ago
HTTP daemons remain pretty nice, and if you use them rather than serving HTTP from your language (... and how many languages are you using? Each HTTP-serving lib is another liability) you get a lot of cool stuff "for free" ("just" config against a battle-hardened system, not code)
- scottlamb 3y ago
  The two aren't mutually exclusive. * I agree that you often will want a server such as Caddy/nginx/Apache httpd to be the Internet-facing http server. They give you a lot of nice things like DoS resistance, logging, robust TLS implementations, and dispatch to all the various applications you might be running. * But you need some protocol between that proxy and your application. Like debugnik, I'd prefer to just use HTTP as that protocol rather than something else like FastCGI. I already have to be familiar with HTTP/1.1 in the sense that I both actually know the wire format by heart and know of a huge variety of tools that can directly speak it. 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.
  - wharvle 3y ago
    > 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.
- 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 ago
    My 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.

wharvle 3y ago

HTTP daemons remain pretty nice, and if you use them rather than serving HTTP from your language (... and how many languages are you using? Each HTTP-serving lib is another liability) you get a lot of cool stuff "for free" ("just" config against a battle-hardened system, not code)

scottlamb 3y ago
The two aren't mutually exclusive. * I agree that you often will want a server such as Caddy/nginx/Apache httpd to be the Internet-facing http server. They give you a lot of nice things like DoS resistance, logging, robust TLS implementations, and dispatch to all the various applications you might be running. * But you need some protocol between that proxy and your application. Like debugnik, I'd prefer to just use HTTP as that protocol rather than something else like FastCGI. I already have to be familiar with HTTP/1.1 in the sense that I both actually know the wire format by heart and know of a huge variety of tools that can directly speak it. 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.
- wharvle 3y ago
  > 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.
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 ago
  My 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.