fastcgi web backend

[bar-g]

FastCGI might probably come back (as a web backend, thus implemented differently) but for now it's not available

Originally posted by @jonmz in #113

Most applications that are long-running nowadays offer themselves by means of HTTP instead of FastCGI, which can be easily attached as a web backend

Originally posted by @jonmz in #113

With powerful alternative shells maturing (https://oils.pub/ growing web capabilities) and "uberspace targeting people who want to do things we didn’t anticipate and generally prefer working with a text-based console" and linux shell... (https://u8manual.uberspace.de/)

Could a fastcgi web backend be comming with U8?
Caddy seems to bring support for it.

(i.e. the comeback of a simple, programming language independent, stateless, "drop-in some files and be done" hosting solution, with no need to configure a service supervisor or anything)

[bar-g]

Oh, BTW, note that the author of the oils-for-unix (OSH/YSH shell, a bash-compatible-upgrade-path) itself is also disappointed with regular hosters removing (apache-)fastcgi.
(https://www.oilshell.org/blog/2024/06/cgi.html#fastcgi-i-think-its-dead-as-of-2024)

But he also thinks the fastcgi interface is still interesting, as it's the only generic "Unix-y" interface (clear and exhaustive process concerns, that includes the process management).
(https://www.oilshell.org/blog/2024/06/cgi.html#contrast-gateway-interfaces-that-arent-unix-y)

---

https://lobste.rs/s/xl63ah/fastcgi_forgotten_treasure

[bar-g]

caddy's generic fastcgi config seems to be:

reverse_proxy backend:1234 {
  transport fastcgi {
	root  <path>
	split <at>
	env   <key> <value>
	resolve_root_symlink
	dial_timeout  <duration>
	read_timeout  <duration>
	write_timeout <duration>
	capture_stderr
  }
}