[toast0]

Typically I've run cgi from a directory outside the document root. That's easy, and I think was the defaults?

That said, fork+exec isn't the best for throughput. Especially if the httpd doesn't isolate forking into a separate, barebones, child process, fork+exec involves a lot of kernel work.

FastCGI or some other method to avoid forking for each request is valuable regardless of runtime. If you have a runtime with high startup costs, even more so.

[SahAssar]

> FastCGI or some other method to avoid forking for each request is valuable regardless of runtime. If you have a runtime with high startup costs, even more so.

What's the point of using FastCGI compared to a plain http server then? If you are going to have a persistent server running why not just use the protocol you are already using the semantics of?

[toast0]

I don't generally want or need my application server to serve static files, but I may want to serve them on the same hostname (or maybe I don't).

There's potential benefits for the httpd to manage specifics of client connections as well: If I'm using a single threaded process per request execution model, keep-alive connections really ruin that. Similarly with client transfer-encoding requests, does my application server need to know about that. Does my application server need to understand http/2 or http/3?

You could certainly do a reverse proxy and use HTTP instead of FastCGI as the protocol between the client facing httpd and the application server... although then you miss out on some speciality things like X-Sendfile to accelerate sending of files from the application server without actually transferring them through sockets to the httpd. You could add that to an http proxy too, I suppose.

[SahAssar]

> You could certainly do a reverse proxy and use HTTP instead of FastCGI as the protocol between the client facing httpd and the application server

That's what I meant. Things like X-Sendfile (or X-Accel-Redirect in nginx) works with http backends. Why involve a different protocol to transfer a HTTP request to a backend instead of... HTTP? I really don't get the point of FastCGI over plain HTTP when a reverse proxy is talking to a upstream backend server.

[toast0]

I mean, that protocol doesn't really matter to me, that's why I said "FastCGI or some other method" The important bit is avoiding fork+exec on every request.

FastCGI is binary based, which has benefits, but hopefully a reverse proxy sends well-formed HTTP requests ... but maybe having the application runtime provide an http frontend encourages running the application software directly accessible, which isn't always wise... some of them are really bad at HTTP.