3 ms·
fastcgi is the real elephant in the room. cgi has a reason for existing. a standard calling convention for loading a process with http request info. but fastcgi
by somat 4y ago
fastcgi is the real elephant in the room. cgi has a reason for existing. a standard calling convention for loading a process with http request info. but fastcgi??? it is network server protocol. "hey guys, let transform our http network protocol into another almost but not quite the same network protocol" for crying out loud, why? just stick with http.
I am almost convinced the only reason it exists is that when it came time to replace the process per request to a single process that would handle multiple requests, people had a hard time thinking about it as a server, so when fastcgi came around and said hey we are cgi(it's not) but fast, they bought the name recognition. it almost appears like a scam but I am not sure who the grifters are.
- effie 4y ago> for crying out loud, why? just stick with http. Because on a busy server, it's better to have lower number of interpreter processes than one per HTTP request. So multiple requests need to be passed to a single interpreter process, so there has to be some multiplexing of the requests into single data channel. Also some aspects of HTTP are traditionally handled by the frontend web server, and some requests do not reach the language interpreter (various access denials, client errors, etc.) So simple HTTP between web server and language interpreter on the same machine is not necessarily a particularly great idea; it would inhibit the development and even performance. It makes sense to parse text once and then pass data between programs in binary form. Fastcgi was good enough, so it stuck.