unit
unit copied to clipboard
nginx
add support for FastCGI protocol ?
Can you add fastcgi protocol next to http to unit. In this way we have equivalent of php-fpm as droping replacement. And add support for fast-cgi for all other language supported by unit.
to have drop-in replacement of php-fpm !
generaly you have front reverse proxy infrastructure (nginx/apache) to application backend... and generaly php backend are generaly in fastcgi... generaly in php-fpm ...
Why don't use HTTP instead?
I'd like to mention that some projects are using fastcgi NOT only for php...
The main problem with FastCGI is that it has almost no benefits over HTTP, but much harder to debug and doesn't support common features like TLS and WebSockets. It's a legacy protocol. We think more about HTTP/2 and HTTP/3 support.
Now with HTTP protocol we can't set/send any "server" variables like PATH_INFO generated dynamically by the server (e.g. fastcgi_param PATH_INFO $fastcgi_path_info in Nginx) so it is impossible to have a script like http://domain/index.php/page.
I think support for FastCGI protocol will provide the possibility for creating a more complex configuration.
Fastcgi has the ability to multiplex request like http/2 and are binary protocol like http/2.
Fastcgi not specify the use or not of ssl as underlay.
They work on socket Unix as on tcp... Why not over ssl... And they are used behind reverse proxy like nginx... Not directly from browser...
The main problem with FastCGI is that it has almost no benefits over HTTP
That's probably true in Y O U R cases. Otherwise, I don't think comparing hot and soft is a good idea.
much harder to debug
What exactly are you trying to debug? FastCGI itself is pretty stable and time-tested library. It allows you to transmit data between server and your application, but unlike CGI, w/o per-request process creation (which is overhead, obviously).
If you are talking about debugging application itself, you're probably relying on the framework (or even whole language) that's working on top of FastCGI. In that case, you should use tools&abilities that comes with that framework/language.
doesn't support common features like TLS and WebSockets
Why it should support these features? I could say that pidgin doesn't support video montage and gimp doesn't support reverb effects on sound, etc. Duh.
It's a legacy protocol
If project or technology haven't one thousand commits during last month, maybe it's not outdated? Maybe it's just done and there is no sense to integrate blackjack and hookers?
Fastcgi not specify the use or not of ssl as underlay
Nowadays we got new shiny&modern way to build your applications - distribute application parts over instances. Good idea, but usually these instances are in same LAN/intranet, so there is no reason to encrypt/decrypt data. If your application server is far away from web server, maybe it's good idea to use tunneling with encrypting?
And they are used behind reverse proxy like nginx...
They are used to communicate between app and web server
Not directly from browser...
Because, again, it's not supposed to interact with browser?
My reasoning is the same as @avkarenow's. I'd like to pass CGI variables from frontend to backend server.
I'd be interested in having FastCGI support as well.
The other thing is that I'd like to also see a UNIX listeners, in addition to inet ones.
This doesn't really fit in with Units architecture.
For most languages, the language runtime runs in process and the HTTP request is passed from the router process to the application process via shared memory.
Even with a C application I had that used FastCGI, it was trivial to convert it to link with libunit and then run it as an "external" application.
the idea is to add FastCGI parser at the same place of the http parser (in the router process). in that way the Unit router front architecture are abel to receive FastCGI protocol and translate FastCGI param in header.
the FastCGI protocol is quasi 1 - 1 with http protocol, but all are binary encoded like http2, and support request multiplexing (but majority of the implementation not support it...is why must be disabled by default...) like http2...
we would use fastcgi to do incremental modernization.
today, we have nginx <-> fastcgi <-> python and changing to unit <-> python directly seems very dangerous, and something would break.
with fastcgi support, the idea would be to do a two-step modernization:
- first
unit <-> fastcgi <-> python, wait a few weeks to validate the configuration of unit - second remove fastcgi and get a proper
unit <-> python
per the comment of @mcarbonneaux one could do the same to gradually and safely get rid of php-fpm.
We appreciate the use case, but FastCGI support is not currently on our roadmap. We would, however, be interested in discussing and reviewing potential patches.
ftr, considering a small go module for unit which would use https://github.com/yookoala/gofast/ to make the fastcgi call.