3 ms·
> 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 serve
by selcuka 6mo ago
> 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.
- assimpleaspossi 6mo agoYour last sentence is exactly what I said.
- anon7000 6mo agoThe article is really exclusively about the reverse proxy server to server use case, not client to server. The title even says it.
- assimpleaspossi 6mo agoI responded to the comment, not the article.
- opello 6mo agoYou 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.
- assimpleaspossi 6mo agoI was responding to the comment, not the article.
- opello 6mo ago> I agree with the article, FastCGI is better than HTTP for these things. If this is what you mean to identify as claiming FastCGI and HTTP are generally interchangeable, and are rising to correct, I'll also offer that "agree with the article" and "these things" narrow the context to "for reverse proxy communication" and do not suggest the broader meaning you've interpreted.