FastCGI: 30 Years Old and Still the Better Protocol for Reverse Proxies

Posted by BrewedDoritos@reddit | programming | View on Reddit | 11 comments

[-]

admalledd@reddit

CGI, FastCGI, etc all died a death for a multitude of good reasons. HTTP Desync attacks are a problem, yes. IMO most of that is reverse-proxies allowing HTTP methods that should just be outright rejected. Be more aggressive in dropping/rejecting, and enforcing aggressive backend connection recycling most current fears become moot. IE, setting an allow-list of headers per HTTP method and only allowing specific known/validated HTTP methods has long been a known prevention for HTTP Desync.

Generally, stop putting multiple applications behind so many reverse proxies (many companies do the "we have one frontent proxy/LB for all apps/tools/things"), and instead actually configure them per-application.

... And also probably set/enforce HTTP/2 only. If you can't then the debate about reverse proxies vs FastCGI vs ... is a whole different topic and challenge, since likely you are living with having to use legacy systems or vendor apps/libraries that can't.

I am however not against the argument of "we need a new, better LB/Frontend-to-backend protocol". There are so many gaps in the current HTTP2, notably in the "how can LB/Reverse-Proxy attach metadata such as source IP, rate limit info, etc" in a trusted sense that can never conflict with other HTTP client/server headers.

[-]

levir@reddit

FastCGI is far from dead. It's the recommended way to connect to PHP, which is still the most popular language for dynamic content. It's also sporadically used for other langugages.

[-]

HealthPuzzleheaded@reddit

Now we have better things like Frankenphp so no need for fastcgi at all.

[-]

Revolutionary_Ad7262@reddit

CGI is a good example of evolution, which creates sup-optimal solutions, because it is based on prior work

It make sense to design a dynamic web servers based on static web server with plugins, if static web server is all you had back then, but in retrospect it is so stupid and generates so many problems

[-]

BinaryRockStar@reddit

At the end of the day the entire web stack (at least) is there because someone blurted out an initial version of something and we've been slowly iterating on it since then. See: HTTP, JavaScript, CSV, PHP.

We need to wipe the slate clean and start afresh with a new modern stack to replace all this cruft! [Insert XKCD link here]

[-]

lelanthran@reddit

CGI, FastCGI, etc all died a death for a multitude of good reasons

FastCGI isn't dead. What do you think the f in php-fpm means?

[-]

Ancillas@reddit

The chorus of central IT/Security, or whatever you want to call it, at enterprises across the land is that dev teams can be trusted with securing customer data, handling audit compliance, and generating revenue, but they must NEVER be allowed to manage their own proxy or threat detection. There’s no way they could collaborate! It is simply beyond their capabilities.

[-]

nicks_bars@reddit

based on the 3rd meeting on this exact topic, neither do they. its hard not to clearly state - i'm handing you the answer on a silver platter with enough meat left on the bone so you feel like you did something, why does this take 3 weeks and additional staff from other departments. $$

quit tormenting after hours you two!