Comment by lelanthran

> Is FastCGI actually bringing anything to the table?,

Yes; it removes the need for the application server to perform parsing of HTTP, which is notoriously difficult to consistently do safely. The application server can use the safer and simpler FastCGI protocol rather than try to support the full HTTP spec.

> Is it actually more difficult to have a HTTP server instead of a FastCGI server if they are so trivially connected?

IME, yes. HTTP (the spec) is full of footguns. FastCGI has fewer footguns. HTTP requires a long dependency chain in your application. FastCGI requires maybe a single library.

> But I feel that your internal HTTP(application) servers should be built as if they were going directly on the open web.

I feel that too, but which developer do you know writes their own HTTP server inside their application? They all use the most popular server via a library or framework, almost all of which warn not to open that to the public internet.

What do you propose they do? They use a framework/library and get a warning not to expose it to the public internet, they don't use a framework/library and odds are good that they coded some vulnerability into it.