Hacker News Reader

Comment by no_wizard | Hacker News Reader

I can’t find any good information on implementing a fastcgi compliant server. Does anyone happen to have information about how to do this? I think it would work well for some applications I have and I can’t find anything to increase my know how to take in incoming fastcgi requests. Think nodejs in particular but language agnostic documents would be best

View on HN

Go supports FastCGI out of the box (and regular CGI) and might not be a bad place to look, unless I'm misunderstanding what you're asking:

https://golang.org/pkg/net/http/fcgi/

Underlying code:

https://golang.org/src/net/http/fcgi/

Edit:

They also link to a 'unofficial' spec they referenced it seems https://fast-cgi.github.io/

I can't tell you how to implement one from scratch if that's your question, but I use apache httpd with mod_fcgi.

This server isn't directly exposed, only valid requests are proxied to it.

I have no reason to think this is the best approach, it's a near forgotten foundational layer of an application that has been stable and reliable for a decade, that is under constant attack and regularly pen-tested.

And to pair with this, Caddy has a fastcgi transport for the proxy module https://caddyserver.com/docs/caddyfile/directives/reverse_pr...

Or if you're running PHP, this shortcut usually does the right thing: https://caddyserver.com/docs/caddyfile/directives/php_fastcg...

It's generally something like:

1. Configure webserver (apache, lighttpd, etc) to forward certain routes to a particular unix socket (i.e. `/tmp/fcgi.sock`)

2. Create and launch a C/C++ process that links in libfcgi.so (or similar) and has an event loop reading from the same socket (i.e. `/tmp/fcgi.sock`)

After that the webserver will forward incoming requests that match to the C/C++ process over socket.

And probably add logic to allow the web server to restart the process if it should fail/crash and maybe recycle it ever Nth hour. Bad C++ code could easily make your process crash.

Apache's mod_fastcgi/mod_fcgid used to try and manage its own FastCGI processes, but the result was rather brittle. It was also a non-starter when the FastCGI processes were on a different machine for load balancing purposes.

It's much simpler to use an independent monitoring program to manage your processes than to rely on the web server. Modern init systems can do this for you, or you can use tools like monit. Docker will probably work, too. Node has PM2. PHP has FPM, which can automatically recycle processes on a preconfigured schedule. Not that they need to be recycled, because PHP is very stable these days, but it's just a one-liner in a config file if you need it.

you should use mod_proxy_fcgi now

Would the socket be in /run now?

I don't think it matters too much where it is as long as it is in RAM and both the webserver and fcgi process have read/write permission on it.

Implementing fastcgi is a lot of fun, and by far not the hardest protocol out there. It's certainly easier than HTTP/1.1, HTTP/2, and (elder gods have pity on us) HTTP/3. So if you don't have access to a library that does it for you, going by the spec will get you there.

There's a bunch of copies of the original specifications floating around still. For ex, http://www.mit.edu/~yandros/doc/specs/fcgi-spec.html

see https://github.com/FastCGI-Archives

where you will be able to find FastCGI Developer's Kit sources and documentations

If you're working with a stack like nodejs, I don't see how FastCGI would be any faster or better in any way.

In the late 90s I used FastCGI with Perl to basically do everything... personal sites, the local Lee Newspaper, even a math expert system funded by a NSF grant that interfaced with MatLab. Nowadays, http server extensions and cloud services easily match FastCGI performance, while providing many scaling and logging and denial of service protections and features built in. It's hard to argue for FastCGI anymore, but everyone wants to reinvent the wheel, and some of those wheels are nice. Who needs EDI when we have SOAP? Who needs either when we have REST.

A fastcgi (or similar, uwsgi is great) server gives you a lot of control over the application lifetime that you have to implement on your own if you use http.

You also have less control over buffering and since you don't see the actual connection, you have to rely on special headers to get things like remote ip and remote protocol. Not a big deal, but still nice.

Reply on news.ycombinator.com