Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

agwa.name

Post reply on HN
Print view View original

61–70 of 107 posts

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

#61

Post by xp84 »

> Only if True-Client-IP doesn't exist does it use X-Real-IP. So even if your proxy does the right thing with X-Real-IP, you can still be pwned by an attacker sending a True-Client-IP header.

Can we just take a moment to appreciate the absurdity of HTTP headers for a moment? We have X-Forwarded-For, X-Real-IP, each CDN has their own custom flavored one. Some of them are a comma-separated list, and usually ends up having an IP of your own LB uselessly added in there (I know why, it's just not helpful). All of them might be inserted by a malicious user-agent. I guess nobody could agree on how all the various trusted servers in the pipeline should convey the important bit.

I guess it fits in quite well with the absurdity of the User-Agent header, which has come so far in absurdity that Apple decided to fully kill it by just sending utterly fake nonsense (false OS version, etc) in the name of "pRiVaCy."

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

#63

Post by selcuka »

assimpleaspossi wrote: post #56
max_k wrote: post #23

I agree with the article, FastCGI is better than HTTP for these things. Though I'd like to make another protocol known: Web Application Socket (WAS). I designed it 16 years ago at my dayjob because I thought FastCGI still wasn't good enough. Instead of packing bulk data inside frames on the main socket, WAS has a control socket plus two pipes (raw request+response body). Both the WAS application and the web server ca…

>>FastCGI is better than HTTP for these things. FastCGI and HTTP are at two different levels. HTTP is for data transfer from, say, a browser and a server. FastCGI is for handling that data between the server and an application. Just now I glanced at the article and it seems the author writes in a confusing way to imply that HTTP and FastCGI are interchangeable and they are not. fwiw, I used fcgi for a decade for all…

> FastCGI and HTTP are at two different levels. HTTP is for data transfer from, say, a browser and a server. FastCGI is for handling that data between the server and an application.

Not entirely correct. A reverse proxy can either speak HTTP, or a different protocol such as FastCGI with the application server. The article is talking about that communication.

They are not interchangeable for the browser-to-server communication, but they are for the server-to-application piece.

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

#64

Post by dspillett »

mikestorrent wrote: post #43
shevy-java wrote: post #15

Earlier quoted context omitted.

What I dislike about nginx is ... the documentation. I find it virtually useless because of that. Sadly httpd went the way of "let's make the configuration difficult"; I abandoned it when they suddenly changed the configuration format. I could have adjusted, but I switched to lighttpd (and also, past that point I let ruby autogenerate any configuration format, so technically I could return to httpd, but I don't want…

Nginx is extremely well represented in AI training material, so virtually every decent model - even locally hosted ones - can deliver you solid answers about its config settings.

Call me an old crusty Luddite if you will, after all you'd not be wrong, but…

I feel that if I can't work something out without asking a generative ML model, then I probably don't understand it well enough to properly assess the generated answer, and if I didn't understand the documentation well enough in the first place then “verify it against the documentation” is not a suitable answer, so I probably shouldn't be self-hosting that system on the open network.

It is quite irritating that the existence of generative models is apparently becoming an acceptable excuse for inadequate documentation. Rather than suggesting that I ask copilot when the documentation Azure is lacking, perhaps MS should as copilot to generate some better documentation (and have their human domain experts review it for correctness) so we have good documentation to work from. It strikes me that them using a bunch of LLM crunching power up-front is likely to me more efficient than a great many of us spending smaller amounts or resources each (many of us asking the same questions) at the point of consumption.

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

#65

Post by scottlamb »

assimpleaspossi wrote: post #56
max_k wrote: post #23

I agree with the article, FastCGI is better than HTTP for these things. Though I'd like to make another protocol known: Web Application Socket (WAS). I designed it 16 years ago at my dayjob because I thought FastCGI still wasn't good enough. Instead of packing bulk data inside frames on the main socket, WAS has a control socket plus two pipes (raw request+response body). Both the WAS application and the web server ca…

>>FastCGI is better than HTTP for these things. FastCGI and HTTP are at two different levels. HTTP is for data transfer from, say, a browser and a server. FastCGI is for handling that data between the server and an application. Just now I glanced at the article and it seems the author writes in a confusing way to imply that HTTP and FastCGI are interchangeable and they are not. fwiw, I used fcgi for a decade for all…

>> FastCGI is better than HTTP for these things.

> FastCGI and HTTP are at two different levels. HTTP is for data transfer from, say, a browser and a server. FastCGI is for handling that data between the server and an application. Just now I glanced at the article and it seems the author writes in a confusing way to imply that HTTP and FastCGI are interchangeable and they are not.

That might be just you. The article is littered with the qualifier "for reverse proxies", including in the title and two section headers, and "as the protocol between reverse proxies and backends" in the second paragraph. I don't know how it could be any more clear on this point.

The max_k comment you've quoted includes "for these things"; context clues suggest by "these things" he also means to limit his comment to the reverse proxy backend leg.

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

#66

Post by inetknght »

jollyllama wrote: post #8
sscaryterry wrote: post #5

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

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.

> an IIS server

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

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

#67

Post by assimpleaspossi »

selcuka wrote: post #63
assimpleaspossi wrote: post #56

Earlier quoted context omitted.

>>FastCGI is better than HTTP for these things. FastCGI and HTTP are at two different levels. HTTP is for data transfer from, say, a browser and a server. FastCGI is for handling that data between the server and an application. Just now I glanced at the article and it seems the author writes in a confusing way to imply that HTTP and FastCGI are interchangeable and they are not. fwiw, I used fcgi for a decade for all…

> FastCGI and HTTP are at two different levels. HTTP is for data transfer from, say, a browser and a server. FastCGI is for handling that data between the server and an application. Not entirely correct. A reverse proxy can either speak HTTP, or a different protocol such as FastCGI with the application server. The article is talking about that communication. They are not interchangeable for the browser-to-server comm…

Your last sentence is exactly what I said.

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

#68

Post by assimpleaspossi »

afavour wrote: post #58
assimpleaspossi wrote: post #56

Earlier quoted context omitted.

>>FastCGI is better than HTTP for these things. FastCGI and HTTP are at two different levels. HTTP is for data transfer from, say, a browser and a server. FastCGI is for handling that data between the server and an application. Just now I glanced at the article and it seems the author writes in a confusing way to imply that HTTP and FastCGI are interchangeable and they are not. fwiw, I used fcgi for a decade for all…

I feel like the author of an alternative protocol probably knows these things. I think the author mentions HTTP because many people use it where they could be using FastCGI and just don’t.

Please note that it's called FastCGI, not FastHTTP.

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

#69

Post by anon7000 »

assimpleaspossi wrote: post #67
selcuka wrote: post #63

Earlier quoted context omitted.

> FastCGI and HTTP are at two different levels. HTTP is for data transfer from, say, a browser and a server. FastCGI is for handling that data between the server and an application. Not entirely correct. A reverse proxy can either speak HTTP, or a different protocol such as FastCGI with the application server. The article is talking about that communication. They are not interchangeable for the browser-to-server comm…

Your last sentence is exactly what I said.

The article is really exclusively about the reverse proxy server to server use case, not client to server. The title even says it.

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

#70

Post by opello »

assimpleaspossi wrote: post #67
selcuka wrote: post #63

Earlier quoted context omitted.

> FastCGI and HTTP are at two different levels. HTTP is for data transfer from, say, a browser and a server. FastCGI is for handling that data between the server and an application. Not entirely correct. A reverse proxy can either speak HTTP, or a different protocol such as FastCGI with the application server. The article is talking about that communication. They are not interchangeable for the browser-to-server comm…

Your last sentence is exactly what I said.

You didn't though. You may have intended to?

The article points out that HTTP and FastCGI are both options for reverse proxies to communicate to the downstream server. I didn't find a reference to them being interchangeable outside of that context. If there is or was one please quote it.

Post reply on HN