# CGI and FastCGI SAPI - Thread: https://externals.io/message/44585 - Original archive: https://news-web.php.net/php.internals/44585 - Started by Gelu Kelunden on 2009-07-01T18:02:06+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #44585 — Gelu Kelunden — 2009-07-01T18:02:06+00:00 URL: https://externals.io/message/44585#44585 Hi, I'm trying to understand how difficult it is to create a new SAPI, so I started to poke my nose inside the "cgi" SAPI source code. I saw that "cgi_main.c" implements both the CGI and the FastCGI protocols and I kinda got lost inside all those if-else lines (I tried to take out the FastCGI code and failed miserably). I'm wondering if it's not better to have 2 different SAPIs, one for CGI and for FastCGI. Advantages of this "split" would be: - the source code will be more readable without all those if-else statements - we would have 2 executables that do 2 different jobs, unlike now where php-cgi does both; each executable could then be further optimized for the exact job they are performing Disadvantages I see: - maintaning 2 SAPI implementaion would require more work (since CGI and FastCGI both share most of the SAPI code, any change would have to be replicated twice) - break backward compatibility (where php-cgi handles both CGI and FastCGI) Thank you for your time, Gelu --- ## #44586 — Michael Shadle — 2009-07-01T18:17:05+00:00 URL: https://externals.io/message/44585#44586 · In reply to: #44585 I think it would be a good idea to also include PHP-FPM in your investigation. > Hi, > > I'm trying to understand how difficult it is to create a new SAPI, so I > started to poke my nose inside the "cgi" SAPI source code. I saw that > "cgi_main.c" implements both the CGI and the FastCGI protocols and I kinda > got lost inside all those if-else lines (I tried to take out the FastCGI > code and failed miserably). I'm wondering if it's not better to have 2 > different SAPIs, one for CGI and for FastCGI. > > Advantages of this "split" would be: > - the source code will be more readable without all those if-else statements > - we would have 2 executables that do 2 different jobs, unlike now where > php-cgi does both; each executable could then be further optimized for the > exact job they are performing > > Disadvantages I see: > - maintaning 2 SAPI implementaion would require more work (since CGI and > FastCGI both share most of the SAPI code, any change would have to be > replicated twice) > - break backward compatibility (where php-cgi handles both CGI and FastCGI) > > Thank you for your time, > Gelu --- ## #44590 — Gelu Kelunden — 2009-07-01T18:37:17+00:00 URL: https://externals.io/message/44585#44590 · In reply to: #44586 I think that the official FastCGI implementation will eventually evolve into something like PHP-FPM, if not even more. What I'm saying is that code that handles daemonization (uid/gid/chroot/log), workers mgmt (spawing/safe-shutdown), daemon config file (not php.ini or php-cgi.ini) should not be present in the pure CGI SAPI implementation, but in a different FastCGI-only SAPI. Gelu "Michael Shadle" wrote in message news:bd9320b30907011117q4fc2c2c3hbffbf289679e6b9a@mail.gmail.com... >I think it would be a good idea to also include PHP-FPM in your >investigation. > > > > […] --- ## #44594 — Gwynne Raskind — 2009-07-01T18:58:12+00:00 URL: https://externals.io/message/44585#44594 · In reply to: #44590 > I think that the official FastCGI implementation will eventually > evolve into something like PHP-FPM, if not even more. > > What I'm saying is that code that handles daemonization (uid/gid/ > chroot/log), workers mgmt (spawing/safe-shutdown), daemon config > file (not php.ini or php-cgi.ini) should not be present in the pure > CGI SAPI implementation, but in a different FastCGI-only SAPI. This seems to me as if it would be a step backwards. For a long time CGI and FastCGI were highly separate setups; you had to use configure flags to enable FastCGI, and so forth. In 5.3 they were unified completely: you can't have one without the other anymore. Why would you need to? -- Gwynne > "Michael Shadle" wrote in message news:bd9320b30907011117q4fc2c2c3hbffbf289679e6b9a@mail.gmail.com > ... > > […] --- ## #44597 — Gelu Kelunden — 2009-07-01T19:26:40+00:00 URL: https://externals.io/message/44585#44597 · In reply to: #44594 Actually I see it a step forward. In the beginning, the "cgi" SAPI implemented only the CGI protocol. Support for FastCGI was added gradually on top of the pure CGI implementation. In order to test this "non-stable" code, one would have to use "--enable-fastcgi". Now FastCGI code is stable enough (and also FastCGI got more widespread and now is "the" way to do it) to be built by default. And, as of 5.3.0, you cannot build a CGI-only executable anymore. New features will definately be added to the FastCGI implementation and I this it might be good to make the FastCGI SAPI stand-alone and not keep arround the CGI-only legacy code. Gelu "Gwynne Raskind" wrote in message news:96158496-0C9A-4568-9A74-2D606730D09A@darkrainfall.org... > > > […] > > This seems to me as if it would be a step backwards. For a long time CGI > and FastCGI were highly separate setups; you had to use configure flags > to enable FastCGI, and so forth. In 5.3 they were unified completely: you > can't have one without the other anymore. Why would you need to? > > -- Gwynne > > > […] --- ## #44599 — Michael Shadle — 2009-07-01T19:43:47+00:00 URL: https://externals.io/message/44585#44599 · In reply to: #44597 Any way you guys decide to do it, I think taking learnings and/or code directly from PHP-FPM could be key to base this off of. One suggestion might be improving the hooks into PHP so that the process management component can be done separately. This would allow for distributions to send it as a separate package and the configuration portion of the FPM can be done in "userland" as opposed to PHP internally. PHP just needs the hooks into it. I've already got the following folks in related discussions, which I believe are the key players in who can help make the decisions on what to adopt, etc. Stanislav Malyshev Dmitry Stogov Andrei Nigmatulin Andi Gutmans Just waiting to have the rubber hit the road and determine the next steps. Another benefit to adding only the required hooks into PHP core and keeping FPM in PECL or something else is so that the adaptive process spawning, angel process creation (which I think would be required for adaptive monitoring) and other features that never got finished or I'd like to see implemented could be implemented independent of PHP development, and PHP core would only need to be patched if something required a new hook that a PECL/external module or controller could not handle. I'd rather see it done in that fashion probably, as waiting for the next even minor version of PHP for certain FPM features might take a while, and I have a "wishlist" which I'd like to turn into a "roadmap" for the FPM functionality, and PHP has a large codebase that can't move as fast as I'd like for FPM if it was just merged directly in. > Actually I see it a step forward. > > In the beginning, the "cgi" SAPI implemented only the CGI protocol. Support > for FastCGI was added gradually on top of the pure CGI implementation. In > order to test this "non-stable" code, one would have to use > "--enable-fastcgi". > > Now FastCGI code is stable enough (and also FastCGI got more widespread and > now is "the" way to do it) to be built by default. And, as of 5.3.0, you > cannot build a CGI-only executable anymore. > > New features will definately be added to the FastCGI implementation and I > this it might be good to make the FastCGI SAPI stand-alone and not keep > arround the CGI-only legacy code. > > Gelu > > > "Gwynne Raskind" wrote in message > news:96158496-0C9A-4568-9A74-2D606730D09A@darkrainfall.org... > > […]