search

nginx / unit

NGINX Unit - universal web app server - a lightweight and versatile open source server that simplifies the application stack by natively executing application code across eight different programming language runtimes.
https://unit.nginx.org
Apache License 2.0
5.4k stars 328 forks source link

add support for FastCGI protocol ? #127

Open mcarbonneaux opened 6 years ago

mcarbonneaux commented 6 years ago

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.

VBart commented 6 years ago

Why don't use HTTP instead?

mcarbonneaux commented 6 years ago

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 ...

xdevelnet commented 5 years ago

Why don't use HTTP instead?

I'd like to mention that some projects are using fastcgi NOT only for php...

VBart commented 5 years ago

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.

avkarenow commented 5 years ago

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.

mcarbonneaux commented 5 years ago

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...

xdevelnet commented 5 years ago

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?

lubo commented 5 years ago

My reasoning is the same as @avkarenow's. I'd like to pass CGI variables from frontend to backend server.

jurajlutter commented 3 years ago

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.

erfan-ilyas commented 3 months ago

FastCGI support would be great.

ac000 commented 3 months ago

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.

mcarbonneaux commented 3 months ago

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...

monperrus commented 3 months ago

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:

per the comment of @mcarbonneaux one could do the same to gradually and safely get rid of php-fpm.

callahad commented 2 months ago

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.