FastCGI: 30 years old and still the better protocol for reverse proxies

Posted by agwa 13 hours ago

FastCGI: 30 years old and still the better protocol for reverse proxies(www.agwa.name)

282 points | 67 commentspage 2

athrowaway3z 10 hours ago|

This seems like really bad advice or am i missing something?

Using fastcgi requires you write your app to serve fastcgi.

The upside of serving http/1.1 instead of fastcgi is that devs can instantly use their browser to test things instead of having to setup a reverse proxy on their machine.

The bad parts of http/1.1 are fixed equally well by both http/2.0 and fastcgi. So just use http/2.0 and you get the proper framing as well as browser support.

agwa 10 hours ago|

Please see the section about untrusted headers - this is not fixed by HTTP/2.

You're right that being able to point your browser right at the app is very convenient. With Go, you can have a command line flag that switches between http.Serve (for development) and fcgi.Serve (for production).

enneff 6 hours ago||

In my experience having different serving paths for dev vs production is a recipe for annoying issues. I try to make dev as similar to prod as possible.

I’m not sure, I don’t dismiss fcgi outright here, I find the arguments for it compelling (not a huge fan of http for many reasons) but it has to be really worth it to break the consistency of using http everywhere.

agwa 6 hours ago||

If you want your dev environment to be as similar to prod as possible, and you use a proxy in prod, then you should use a proxy in dev also. I was presenting a solution to someone who doesn't want to do that.

enneff 5 hours ago||

I think perhaps I was unclear. I don’t mean the entire dev environment should mirror prod (although it’s great if you can do this for end to end testing). I just mean it’s desirable if the process you’re working on operates the same way in dev as in prod.

est 4 hours ago||

Then there's uwsgi protocol. It's also an RPC for basically everything.

blipvert 6 hours ago||

(u)WSGI must surely get a mention here?!

Tepix 10 hours ago||

I‘ve had good experiences with FastCGI back when Perl was popular. These days, WebTransport is the new sexy thing. Probably not a real FastCGI replacement.

daneel_w 9 hours ago||

I've built a lot of API backends with Perl and FCGI::ProcManager, letting nginx (and Apache HTTPd in the past) front everything. For me it has been a pleasantly simple, incredibly robust and high-performing setup with no mess to speak of.

simonw 10 hours ago||

As I understand it FastCGI doesn't handle websockets, which is a shame. It should be able to handle SSE though since that's effectively just a regular slow-loading/streaming HTTP response.

sscaryterry 11 hours ago||

I've fought many battles with perl + windows + apache + FastCGI in a previous life. No thank you.

jollyllama 11 hours ago||

Indeed. I'm sure that someone will butt in with "it's just a bad implementation!" but the whole bit about allowlisting communications will cause flashbacks in those of us who had all our PUT requests just quit working on an IIS server.

inetknght 4 hours ago||

> an IIS server

There's a reason the internet runs on Linux...

scotty79 10 hours ago||

What I'd like to see is someone creating local caching proxy for modern https infested world. I'm fed up with downloading same packages 100 times.

ebb_earl_co 8 hours ago||

I’m in the same boat. Am trying to figure out how to configure Vinyl cache (née Varnish) in my home lab.

majorchord 7 hours ago||

Can't squid do this?

shevy-java 11 hours ago||

I'd love for CGI to be updated, kind of merging what works and not really caring about what does not work. Getting a .cgi file to work on Linux is really easy. Naturally you get more leverage with e. g. rails, but there is also a lot more complexity and I really hate intrinsic complexity.

somat 10 hours ago||

CGI and FastCGI are two different things in two different domains. Well the domains are not that different but enough that CGI solves a real problem and makes sense and FastCGI does not. CGI is the interface between a HTTP transaction and a process. It answers the question "How do we turn a HTTP request into executing a process?". FastCGI answers the question of "How do we turn a HTTP request into a FastCGI request". a convolution that leaves you asking "Why are we jumping through this hoop? Is FastCGI actually bringing anything to the table?, Is it actually more difficult to have a HTTP server instead of a FastCGI server if they are so trivially connected?

I am halfway convinced the only reason FastCGI exists is we had got in a mindset that executable code in a HTTP context had to run via the Common Gateway Interface and when we wanted to to change to a persistent process model it had to have the CGI name as well. Well FastCGI to the rescue it does exactly what HTTP does but is not HTTP and most importantly has CGI in the name.

As to the articles complaint, "A HTTP relay server had a bug. Therefore HTTP is intrinsically bad". Well.. it failed to convince me. I am not exactly in that domain(backend web development) so my view is not worth much. But I feel that your internal HTTP(application) servers should be built as if they were going directly on the open web. Then you put some relay servers in front in order to block, balance and route requests. But avoid putting too many smarts in the relay servers. A smart network is almost always a bad idea. try and stick with a dumb network and smart edges.

PunchyHamster 8 hours ago||

Embedding http server (or fcgi one for that matter) is trivial in most languages and also makes local development simpler. CGI was horrible idea back then and it continues to be

teddy_oweh 3 hours ago|

[flagged]