FastCGI: 30 Years Old and Still the Better Protocol for Reverse Proxies
Posted by BrewedDoritos@reddit | programming | View on Reddit | 11 comments
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
FastCGI isn't dead. What do you think the
finphp-fpmmeans?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.
/s
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!
tetyys@reddit
http must die
HighRising2711@reddit
I think yours is a minority view
Forty-Bot@reddit
SCGI is a simpler and cleaner protocol with wide suport. FastCGI has a bunch of features (e.g. request multiplexing) that complicate the protocol and aren't used very often.