I've fought many battles with perl + windows + apache + FastCGI in a previous life. No thank you.
I have already tried to build houses with sand, I'm not falling for your "concrete" idea!
FastCGI: 30 years old and still the better protocol for reverse proxies
101–107 of 107 posts
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#102Earlier 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. That might be just you. The article…
I didn't quote anything from the article. I was responding to the comment, not the article.
> I didn't quote anything from the article.
You referred to it: "just now I glanced at the article and it seems the author writes in a confusing way..."
> I was responding to the comment, not the article.
It sure looks like you were responding to both, and I addressed both. Also, you're going to have a hard time understanding HN comments if you don't read top-level comments as responses to the article, even if they don't start with "I agree with the article" as max_k's comment did.
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#103Earlier quoted context omitted.
These are often not enough ‘battle-tested” and come with a warning to never expose to public internet. So then you put a WAF in front of it, and you are back to HTTP reverse proxy setup.
I've always chuckled at this. Just don't used bad HTTP server libraries. I wouldn't put something like that on my intranet either. But even if you disagree with me the point is that I can count on only one hand the number of times I went "oh man, I need a FastCGI middle end".
I agree with your point but this is the reality:
F.E. Python stdlib http.server comes with a warning: Warning http.server is not recommended for production. It only implements basic security checks.
The `standard` way is then to use WSGI or ASGI, not FastCGI, but it is similar interface implementation.
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#104Earlier quoted context omitted.
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.
Again, you’re pointing out things that are obvious to those involved and I’m not sure why.
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#105Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#106Earlier quoted context omitted.
And I was saying his comment is wrong. Sometimes HN can be just so reddit-like.
His comment is _not_ wrong. He says "I agree with the article, FastCGI is better than HTTP for these things." "These things" being the communication between a proxy and the backend.
Thanks, but I feel we're all just feeding this one troll. Don't bother replying anymore, it's pointless.
Re: FastCGI: 30 years old and still the better protocol for reverse proxies
#107FastCGI is theoretically better does not make it the easier choice in reality, the success of HTTP is just another case of "worse is better"
No, in the case of all the desync attacks that James Kettle has found since, HTTP between servers is more like "worse really is worse." At least until they all speak HTTP/2.