[seanp2k2]

+1 on developers not knowing how HTTP works. I'd add to that with server-side devs (the ones writing the APIs that the single-page apps talk to) not knowing how CGI works. You can literally learn both in an afternoon if you have reasonable networking and OS-level knowledge that I'd expect anyone with a CS major to have down cold. Sadly, well, you know.

In my experience, devs knowing how it really works are the small minority. Most of them seem to know "I put /foo in my Rails router, run `rails s`, hit 127.0.0.1:3000/foo in my browser, and it does the good stuff", which is consequently enough to get by in many development positions at many places.

[laumars]

CGI isn't really something I'd expect many people to be using these days though. These days language web frameworks fire off their own web server and the few exception usually bypass CGI (eg PHP has a mod_php C++ API that hooks directly into Apache bypassing CGI).

Sure you can still run Perl, Python or even Go via CGI on Apache, or PHP using FastCGI on nginx, but the difference in performance between even FastCGI and a language-native web server isn't negligible. So there isn't really much reason to recommend people using CGI barring niche use cases where, hopefully, the sysadmin / devops as purposely chosen CGI acknowledging it's pitfalls (not just in terms of performance but also security) and thus understanding how it works.

This is one of the few areas where I think the additional complexity in modern frameworks is a real benefit.