Re: Why FastCGI?

Greetings, Gunter Grodotzki. In reply to Your message dated Thursday, April 1, 2021, 13:53:06, >> Eh, why? If you do not upload files, you don't need a shared volume. >> > True. I suppose you can just passthrough any “.php” from nginx to fastcgi > without verifying existence and then rely on php-fpm completely to handle failures. > Then of course you would have to ensure that all static files are built > into the nginx container while the php files are in the php-fpm container. I have exactly zero .php files inside a webroot, even though I don't use Docker. nginx is hardcoded to request the front controller script regardless of what was requested. (The SCRIPT_FILENAME var is set to constant value.) >> And will still need shared volume in same cases you would for CGI link. > unless of course - similar to the php built-in you make it also respond to > non-php files. Then you can add nginx as a layer (as mentioned in my > previous post) but they both will work completely independently - file-wise. Exactly. nginx will serve statics from specified location(s), the rest will be sent to the backend. If I want to return the ball from PHP to the nginx, I can use X-Accel-Redirect. >> Er, I use TCP for my PHP FPM. For years. > You are quoting me out of context so it makes little sense. I never said > you couldn’t nor did I say a shared volume is required for fast_cgi_pass. True. It just the discussion made the impression that shared volume is required for FastCGI to operate. Sorry for confusion. >> That says so much about people building these containers… > Always easier to dismiss people than to put yourself in someone else’s shoes > to understand their problem :) I understand their problem. I've been there myself, and even made worse mistakes that some wrong assumptions. -- Sincerely Yours, Andrey Repin <anrdaemon@freemail.ru>