My investigations of problems with using PHP (in this thread) in Caddy on Windows have thrown up the fact the the implementation has problems which are not present in Linux. It is not clear whether these are anybody’s fault (though if anyone, I’d point at the PHP developers); but there seems to be a layer missing which is required.
Fast CGI differs from plain CGI in that instead of generating a new process for each call, it can reuse existing processes which keep running, waiting for new input. At some stage in the execution of a fastcgi call there needs to be some form of control to avoid reentrancy or calling for multithreading beyond what the called process can handle. It is not, however, clear where this should be applied.
Taking the example of PHP, which is the main one in most people’s minds I imagine, the binary availabel from PHP is php-cgi. Now php-cgi does not contain the necessary process management code, as is explicitly noted in the last comment here:
The executable php-cgi.exe that is bundled with the windows binaries is a FastCGI interface but it is not FPM (Fastcgi Process Manager). php-cgi.exe does not have multi-threading or concurrent request support, nor support for any of the FPM configuration options.
Elsewhere I have seen comments that such code is in the source of php-cgi, but is disabled in the Windows compilation. It also appears that php-cgi will only accept a certain (configurable) number of calls before dying (to clear possible memory leaks, they say); a process manager would need to handle that eventuality as well.
For these reasons, PHP supply an additional program php-fpm which implements this management layer before passing requests on to php-cgi. In Linux, fastcgi calls to PHP are always written using php-fpm (I guess the implementation of process management in php-fpm is an improvement in same respect on that in the Linux version of php-cgi).
However, php-fpm is not available for Windows. I believe that this is because it uses Linux mechanisms which have no direct parallel in the Windows environment, and so it would need to be rewritten. For this reason, a web server has to be able to provide this function instead to make fastcgi to PHP reliable. Apache has two alternative layers which provide the requirements: mod_fcgid and mod_proxy_fcgi (the first is far easier to use). IIS has the necessary built in to its fastcgi implementation, and I think Lighttpd does as well.
Now I may have got this quite wrong, and Caddy may have the necessary code. But if that is so it has problems - firstly because of the behaviour discussed in the thread I linked at the start (not being able to handle arbitrary overlapping parallel calls), and secondly (something I have not mentioned before) because there appears to be a huge latency (something like 1 second) in PHP calls through Caddy on my system. Neither of these effects is present when using Apache calling the same php-cgi file through mod_fcgid on the same system, which is why I am currently proxying my PHP subsystems from Caddy to Apache.