←back to thread

Remember FastCGI? (2021)

(brokenco.de)
53 points heavensteeth | 1 comments | 08 Apr 25 12:00 UTC | HN request time: 0.229s | source
Show context
somat ◴[11 Apr 25 15:35 UTC] No.43655047[source]▶
I never really understood the rational for using fastcgi. For everything I wanted to do it always made more sense to just use custom http servers and proxys.

CGI makes sense, it fills a specific environment, one request, one process, but fastCGI? why? its a server with a different incompatible HTTP. did everyone jump on it just because it had CGI in the name and the associativity CGI == web process was too firmly entrenched in peoples minds.

But I am not really in a web ops role, so who knows, perhaps fastcgi does have some sort of advantage when run at scale.

replies(2): >>43659523 #>>43671651 #
1. ianburrell ◴[11 Apr 25 22:49 UTC] No.43659523[source]▶
FastCGI was from time before languages had good HTTP servers. HTTP is complicated, FastCGI is simple. It was also from time when servers were less powerful such that duplicating HTTP parsing was an expense. HTTP parsing is potentially dangerous so safer to do in web server than library. Finally, it was from before the language web APIs (Rack, WSGI, etc) such that the code used CGI interface and FastCGI did that but with separate server.