Unit: add support for FastCGI protocol ?

Created on 30 May 2018 · 8Comments · Source: nginx/unit

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.

Source

mcarbonneaux

Most helpful comment

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.

avkarenow on 8 Feb 2019

👍2

All 8 comments

Why don't use HTTP instead?

VBart on 30 May 2018

👍1

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

mcarbonneaux on 31 May 2018

👍2

Why don't use HTTP instead?

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

xdevelnet on 8 Feb 2019

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.

VBart on 8 Feb 2019

I think support for FastCGI protocol will provide the possibility for creating a more complex configuration.

avkarenow on 8 Feb 2019

👍2

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

mcarbonneaux on 8 Feb 2019

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?